webchick.net

Tomorrow and Saturday, I'm headed off to Drupalcamp Montréal, our first such event in the fair city.

Like all such "Open Spaces" events, we won't really know what the schedule is until tomorrow morning, but here are the sessions I'm planning on giving, in relative order of geekiness:

• What is Drupal and why is it so awesome?
• Contributing to Drupal: A guide for everyone
• State of Drupal 7, co-presented with Damien Tournoud at Drupalcamp Paris 3!
• How to Win Friends and Influence Drupal: A guide to patch review
• SimpleTest: Because clicking on forms is for suckers

So if you're in the area, stop by! It'd be great to meet you!

Thanks so much to Koumbit for making this happen, and evolvingweb for building a website for it in record time. :)

As of this writing, there are over 5,600 active issues in the Drupal core queue. About half of those are listed in the 2,650 active issues for Drupal 7. And the "patch queue for Drupal 7 -- those issues that have at least *some* code to fix them in various stages of completion -- clocks in at 1,040 issues.

These numbers are, quite frankly, staggering. Discouraging, even, some might say. With so many issues out there vying for attention, how are we to find those ones that are really important, such as killer new features, powerful API enhancements, and critical bug fixes? While Drupal 7's development cycle doesn't have an expiration date on it yet, we all know that day will come, and probably sooner than we'd ideally like. What can we do to make sure that important patches are raised to the surface and receive adequate developer and committer attention?

To succeed, we'll need to employ a two-pronged approach: taking out the trash, and digging up the treasure.

Here's another tip for those who are looking for more reviews of their patches and faster commits: describe what the heck your patch does! :)

A simple enough premise, and It sounds obvious, right? But you'd be surprised how few patches are accompanied by a good, solid list of changes.

For a really bad example of this, allow me to pick on our #1 core patch contributor for a moment. Witness http://drupal.org/node/259412. The issue title is "Total module system revamp." The description? Two words: "Drupal diet." Accompanied by a 30K patch that removes and adds all manner of things. Please DO NOT do this. :P Doing this means that anyone who wants to review that patch (or commit it) has to sit down for at least an uninterrupted hour and sift through the diff to figure out what's even going on, before they can even begin to do the actual review to answer things like, "Is this the best way to solve this? Are there additional places we could make improvements? Does the code introduce logic errors?" and so on. Since this is a daunting effort, it means that often times reviewers simply don't bother looking any further at such patches, and so they end up rotting in the queue for months on end.

Most patches aren't this extreme, but they could almost all universally stand to be improved. Let's try to make sure every patch in the queue has the following:

I was recently named Geek of the Week by Maria "Ubergeeke" Webster of .51 - GeekSpace for Women.

I met Maria at OSCON this year, and she is hilarious, friendly, awesome, and possibly an even bigger geek than I am (I know, right? I didn't think it was possible either! ;)).

Her site highlights women geeks who are kicking ass, new technology trends, and all the crazy stuff she is doing. Might be of interest to some of the Drupalchix out there.

Thanks, Maria! :)

Patch authors are always looking for a strategies to help shorten the length of time it takes to go from creating a patch to seeing it reviewed to getting it committed. Here's a quick tip for any patches that involve a UI change: Submit a screen shot with your patch!

Screen shots present a really easy way for anyone, regardless if they are a developer who has a Drupal 7 development environment setup or not, to quickly scan the gist of what the patch does and to provide feedback on whether things need to be changed. And in fact, those people who don't have Drupal 7 development environments are actually the people whose UI feedback we need the most! :)

Naturally, you can also go above and beyond, such as creating an entire video demo. ;) But in most cases, a simple before/after screen shot is sufficient.

So, a little challenge for Drupal core developers out there: let's strive to make sure every UI-changing patch in the queue accompanied by a screen shot. It's an easy way to get more eyes on your stuff, get more types of eyes on your stuff, and sort out the challenges well ahead of commit time.

We've all been there. You sit down to write a "simple" patch. Maybe it upgrades a module to Drupal 6. Maybe it adds a small feature, or fixes a bug that's been annoying you for awhile.

You grab your caffeinated beverage of choice, pop open your text editor/IDE, and throw on your coding tunes. You search through the file for the lines you need to change and... sayyy... You know, the indentation is off a bit here. I'll just go ahead and fix that. Oops. And this function's PHPDoc is missing. No problem, a couple quick lines here. OH! That's clearly a bug. Better fix that while I'm at it. Hey, and that reminds me! I always kind of wished that this particular feature worked a different way. Might as well pop that in while I'm at it...

Suddenly your "simple" patch has grown into 30-40K of changes. It fixes the original thing you set out to fix, and it also makes several improvements to the code that you found as you were going through. Great! So what's the problem?

The problem is context switching.

This afternoon, our rabbit, Oscar, passed away. He's been with us since 1999, a couple months after Marci and I moved into our first apartment in Halifax. Oscar was funny, gentle, smart, and full of personality... we miss him terribly. :(

Marci and I spent some time tonight looking through old photos and reflecting on some of the memories we have of him.

• His "happy dance" where he would run around, flip himself up, and twist around in the air, landing in the opposite direction from which he started.
• When he first met Pickle, who was just a kitten at the time, and made a record 9-foot leap from one end of the hall to the bathroom. Pickle simply meandered off in the other direction nonchalantly, of course.
• When he chewed through the hose connecting the toilet bowl to the plumbing and proceeded to flood the entire bathroom.
• When my brother Keith was holding him, remarking about how cute he was, and Oscar peed in his lap. ;)
• When Bebop was just a kitten, she crawled into his kennel with him and we caught them laying next to each other spooning.
• The way he would "peek" his head up over things to see what was going on on the other side.
• When he wanted attention, he would pick his food dish up in his mouth and fling it around wildly.
• He was once a TV celebrity in Bedford, Nova Scotia.

The Drupalcon Szeged schedule just went up last week. It's jam-packed with interesting sessions ranging from low-level geeky goodness, to design and usability sessions, to Drupal business best practices. And the BoF schedule is filling up with tons of interesting stuff, too.

A list of the sessions I'm leading/partaking in follows the break. But first! I need your help!

Something we're doing this time around is an experiment in community swarming: the Awesome Testing Party. The aim is for both new and established contributors to learn how to write automated tests (and how to contribute to Drupal in general) by practicing with real tests that need writing for Drupal 7, with members of the "Drupal Testing Brigade" on-hand to help answer questions.

It'll work like this:

• People who don't know anything about testing will attend the Intro to Testing session on the first day.
• The next morning, tons of people show up and get some delicious Hungarian pancakes. While they're having breakfast, the testing team will do a quick 10-minute overview on how to write a test as a refresher.
• After the demo, we split the room into "half": people who've written patches on one side, people who haven't on the other. Everyone will be asked to team up with someone from the opposite side. We'll jiggle things around so everyone has a partner.
• Each of the pairs runs up, grabs a card with an issue node ID on it from the ever-growing TestingParty08 pool, and runs back to their laptops. Using the provided hand-outs, and calling on testing experts for one-on-one help, they work together to create a test for their issue.
• Once finished, they roll a patch, attach it to the issue, then come up and get another card... AND... some chocolate! Repeat until there are no more cards! :) At the end, we'll have dorky prizes for pairs with the biggest chocolate collection!

So as you can see, in order for this session to be a complete success, we must have the following:

1. Tons and tons of people there. I mean like TONS of people. New contributors, old contributors, doesn't matter. If you've written one lick of PHP, you should be at this session. It'll be crazy fun.
2. Chocolate! What entices people to write tests more than delicious chocolate from all over the world? Nothing, that's what! So if you're coming to Szeged, please bring some chocolate with you! It doesn't need to be anything fancy (though it does need to be in an unopened package ;)), just a candy bar or whatever. The idea is simply to amass an enormous collection of chocolate from all over the world, and hand it out to people as a reward for completing tests.

So yes. Please come to the testing party, and please bring chocolate to share. We'll do our best to get the critical test queue down to 0, but either way we'll go home with our sweet tooth satisfied. ;)

I just saw this float past the stream in #drupal...

A couple weeks ago, Amber Gillies had asked if she could interview me about Google Summer of Code and my experiences in the Drupal project as part of the piece, Open source technology is hungry for new college grads. Yeah... just *try* to get me to shut up about how awesome GSoC and Drupal are. :D She did a very good job of turning my firehose of an e-mail into coherent sentences. ;)

Edit: Holy crap, this has been Slashdotted, too.

http://google-opensource.blogspot.com/2008/07/and-winners-of-2008-google...
http://drupal.org/webchick-wins-best-contributor-open-source-awards

I have lots I'd like to say about this, but am a bit overwhelmed just at the moment. Suffice it to say, my sincerest thank you to everyone who nominated me for this award, and to O'Reilly, Google, and the Drupal community in general for being so unbelievably awesome.