Corsix.org

I've been chosen as Drupal's grand prize winner for the Google Highly Open Participation Contest. So on top of the $500 I get for completing 15 tasks, I also receive an all-expenses paid trip to the Googleplex in Mountain View, CA for myself and a parent. When I spotted an announcement for GHOP on slashdot back in November, the grand prize looked extremely nice but at the same time, out of reach. I want to say thankyou to the Drupal GHOP admins, mentors and members of the community who helped me from zero Drupal knowledge up to where I am now. Although I'm in the limelight, the real winner here is Drupal itself, with exactly 130 tasks completed by students, all of whom are now more involved in open source.

Where am I going with Drupal?
Now that the organised tasks structure of GHOP has passed, I need to decide on what to do with Drupal, rather than just look at the GHOP task list. Some ideas that I've had:

• Be a student/mentor in DROP - Spurred by the idea of GHOP, the Drupal community has initiated the Drupal really open participation scheme. It uses the same task based workflow as GHOP, but without all the rules and paperwork that were required for GHOP, so anyone of any age can participate, and you're not bound to one claimed task at a time. If GHOP repeats next year, then whatever we learn from DROP should help us shape GHOP slightly better.
• Port the Tarski theme from WordPress to Drupal - I haven't done anything with Drupal themes yet, so a theme based project would help expand my understanding. While the theme I'm currently using (Bluecurves, created for GHOP #11) is purty, I know the creators of Tarski and have contributed fixes to it in the past, so I would like to see it Drupalised
• Views scaffold module - hook_schema already describes a module's database schema, so why can't that be used by Views? Why should module authors have to describe their database tables in hook_schema and then again for Views? It should be possible to create a module which takes the output from a hook_schema and feeds it directly into Views, or generates the code for the Views hook so that module authors can put that into their code.
• Fingerprint module - There was recently a long discussion on drupal.org about the changelog.txt files (and similar such files) present in a default drupal installation, which allow hackers to quickly fingerprint which version of Drupal your site is running (e.g. drupal.org is using 5.6 at the moment). This module would, when given the URL of a site, attempt to determine which version of Drupal the site is using through looking at things like the changelog, the CVS $Id$ of drupal.js, and other such identifiers. Site admins who don't want their sites to be fingerprinted can then look at the identifiers that the fingerprint module uses and specifically make changes to invalidate and confuse such identifiers. So in effect, it would make fingerprinting a Drupal site harder rather than easier - maybe.
• Browse the Drupal issue queue - The issue queue on drupal.org is full of bug reports, feature requests and the like. While Drupal's GHOP admins deliberately avoided wildcard tasks like "Fix a bug in the issue queue" (which I think made Drupal GHOP all the better), now that GHOP is over, it might be a good place to get inspiration on what to work on.

I'm also looking forward to next year's GHOP (if there is one), when I'll hopefully experience GHOP from the mentoring/admin side of things rather than the student side.