GHOP Status Report (Week 2)

Note: This post assumes that you are aware of the Google Highly Open Participation Contest. If not, see that link.

Highlights

As of right now, since the contest's inception on November 28, 2007:

• We've had participation from 42 students, of which 27 (64%) have completed one or more tasks.
• We've had a total of 36 tasks completed so far, in areas such as code, documentation, quality assurance, user interface, outreach, training, research, and translation.
• Of the students who have completed tasks, 60% are *new* contributors who came to Drupal because of this program. Of those, two have already completed 4 tasks and are on their 5th!
• We have over 100 task slots available; we currently have used up 73 out of 200.
• We are desperately short on task contributions from the community. There are currently only 8 remaining tasks for students to choose from!! Unless we can turn this situation around within about 24 hours, students are going to end up going with projects like Joomla! and Python once they finish what they're working on. Yay!! Thanks SO much for your help! Please keep those great task proposals coming! Now what we really need are people to review and improve the existing task ideas so we can get them added to the queue!

Read on for more info on how these students are completely rockin' and how you can help them continue to do so.

So what are all of these students working on, anyway?

Code Improvements

• Code Filter was ported to 6.x by corsix, which is awesome since this is used on drupal.org, so will help us on our way to porting the "mothership" to 6.x!
• While he was at it, corsix set to work and created a patch to fix a long-standing bug in Code Filter's PHP regex.
• Then, corsix went on to Enable Metrics and Version Control API modules to show lines of code changed, which will be important for project ratings on Drupal.org.
• Finally, corsix went on to add an "Execute arbitrary PHP-Code action and condition to workflow-ng module. You might say he's on a roll. ;)
• jvaill added code to support auto-generation of project issues, which is critical for people trying to test project module improvements. His work also uncovered a bug which was subsequently fixed by the maintainers!
• Speaking of Project* module improvements, we're about to get a filter that turns #xxxx into a node link, courtesy of mwrochna, who also got to have a real taste about what working in an open source community is like. ;)
• User titles module now has User points support thanks to ezyang who, instead of doing the task as requested, added a hook instead so that any module can integrate with User Titles.
• CorniI created 2 new simpletests for core.

Videos

• kyl191 made a great video on how to maintain a project with TortoiseCVS for our Windows-based contributors.
• TimRogersCool created both a video on how to use Actions and Trigger module, as well as a companion handbook page!
• Translators Etinin and tkunisky translated the Rolling Patches in Drupal video into Brazilian Portuguese and Russian, respectively, which will greatly help our international developers start contributing.

Usability

• AriX and stallonselvan both sat down with some new folks installing Drupal for the first time, and created usability reports of their findings. Many of their suggestions are currently in the process of being implemented for the forthcoming Drupal 6!
• ezyang worked on a proof of concept for a re-worked module administration page, and has now set his sights on an even fancier implementation
• TimRogersCool helped us out by mocking up suggested improvements to two Drupal administration pages. Always great to have a fresh set of eyes on these things to spot problems. :)
• bjtitus went and took screenshots of all the themes that were missing them. Now, the webmasters team is looking for a way to get these integrated to the themes download listing. Any bright ideas, please post there!

Research

• CorniI did some performance profiling of Drupal 6, and found at least one great optimization that can be made.
• Mgccl performed excellent research into Microformats' use in Drupal, which is currently under discussion by the Microformats working group.
• A fantastic Evaluation of penetration testing security tools was performed by ddcc.
• kourge has reviewed several of the mini modules in the handbook for compliance with security standards.

Documentation

• dstelljes created a funny, awesome recipe on Creating a school newspaper website in Drupal
• All of the module help pages in Druapl 6 have been reviewed by DanW, and there's currently a patch in progress to fix all of these issues in Drupal 6 before string freeze! Please review!
• ThatPerson gave our Your own api.drupal.org site documentation a much-needed touch-up.
• Imagecache at last has some documentation, thanks to the heroic efforts of Etinin.
• binodc worked hard combing through Drupal's Upgrade docs looking for suggested improvements.
• fberci did a great job labeling all theme functions as "themeable" in Drupal 6 so they're available for themers. His patch was subsequently committed to core!
• dereine wrote up some great documentation on How to theme a CCK form 3 distinct ways.
• ezyang helped distill dww's talk at BADCamp into Releases and Update Status documentation, in order to help module maintainers get a handle on the system.
• ezyang struck once more, this time to create an API tutorial for Userpoints module.
• thekiefs created a Comparison document between Drupal and other frameworks which is a great read.

Marketing

• birdmanx35 created a great list of interview questions for Dries Buytaert, Drupal project founder, who has promised to answer them once he is less busy with founding companies and defending PhDs. :)
• cf_al_bs created a series of buttons and banners to promote Drupal 6.
• mbossino whipped up a gorgeous promotional booklet for Drupal 6.

Woah, this sounds awesome! How can I help?

I'm so glad you asked! ;) There are three main ways to help, but the one we need the most help with at the moment is proposing new task ideas (and of course the subsequent mentoring/review of the results of those tasks).

This is a tremendous opportunity both for our community members to get small (~1 week-long) but important tasks looked after that often fall through the cracks due to other things, and for we as an open source community to help enrich a student's life by giving them the opportunity to work along side us in the open source world.

So, please. Please:

• read the "how to write a good task" guideines (synopsis: let's make these fun/interesting/creative/important tasks rather than boring monkey work tasks).
• Take the time to write up your task proposal to sufficient detail. Doing this "right" actually takes a good bit of time; please note that mere task "ideas" aren't very helpful.
• Find a couple of co-mentors for the task to help stay on top of task reviews and such.
• And then, propose your task idea and we'll get it added "officially" once it's approved.

We can also definitely always use help monitoring the GHOP tasks that need review and in #drupal-ghop on irc.freenode.net to answer student questions, if you don't have the time available to mentor a task.

And finally, winter holidays are coming up, when students are likely to have all kinds of time, and adults are likely to be completely swamped. If you have availability over this time (~Dec. 19 - Jan. 2) please get involved to help pick up some of the slack.

Thank you!!

GHOP Task FAQs

In a series of haikus, can you please explain what the qualities are of a good task?

Fun, interesting
High importance to Drupal
Nice on a C.V.

Detailed descriptions
Clear expectations with no
Ambiguity

Mentors are lined up
To turn task around quickly
So more can be claimed

I'm interested in writing up a GHOP task! Can you point me to past successful tasks, so I can, er, "borrow" from their task descriptions?

Absolutely! :)

There have obviously been too many great tasks to list them all, but here is one from some of the major categories, so you can get an idea of the level of detail we're after.

• Code: Citation input filter: Task gives clear example of expected input and expected output, so the student has a "spec" to work from. It's also nice and compartmentalized so it won't "creep" into something large and tangly.
• Documentation: Improve documentation for the imagecache module: Task is both against a module used on thousands of Drupal sites, and also provides an outline of what the expected documentation should contain, so that there's no ambiguity about whether not the entire thing's been covered.
• Usability: Improve initial user experience: Contains both a list of things to check for as part of the user experience research, as well as a clear target to shoot for in terms of expected results.
• Videos: Create a video showing how to install and use TortoiseCVS: Covers all of the material the video should show, sets up guidelines on the length and format of the video, etc. Also is something that will be helpful to a large segment of the Drupal community (developers on Windows).

How about a task like "Go fix some documentation" or "Go port some module to 6.x"?

These are generally referred to as "wildcard" tasks, and are sub-optimal for the following reasons:

• We have no idea what documentation or module they're going to choose and whether or not we'll have enough expertise in the community to adequately review the work.
• We have a limited number of task slots available. We want to ensure that these slots are allocated to high-impact needs that can benefit the larger community.
• They can attract students who are simply after low-hanging fruit so that they can quickly move on to the next task and claim more prizes, rather than those who are interested in becoming long-term contributors in the community.

So, rather than tasks like this, please choose _specific_ documentation that needs fixing or _specific_ modules that need porting and write your tasks around that.

Oh, I've got it! Let's just make 500 copies of the $foo task. Problem solved!

While we could do this, please consider the consequences:

• We only have 200 task slots in total (and now, thanks to everyone's help, only around 100 left un-filled. w00t!). If we use up 20 of them on one area, we're directly taking away from the number of tasks we can spend in another. We really need to decide whether that thing is really worth using up 20% of our remaining slots.
• Remember that each task takes someone to mentor it (or preferably several someones) in order to ensure prompt turnaround on reviews so that students can take more tasks! Creating 20 "Create SimpleTest coverage for X module" tasks is no good if we don't have at least that many people (and preferably more like 50) who are up to speed on SimpleTest and are able to guide students through these tasks.
• If our task list essentially looks like a big copy/paste job, we're going to give the strong impression that we are lazy and aren't putting proper effort into the program. Students are likely, in turn, to not put a lot of effort into us.

Hey, why don't you guys make a task about..?

No. There is no "us guys." The "us guys" administering the program are already tapped at maximum capacity keeping the "plumbing" on the contest side of things running. There are about 5 of us, and over 200,000 of you. In order to scale this program, we need _your_ help.