Note: This is something new I'm playing with, called the "Contributor spotlight." I spend a lot of time on the Drupal.org site (no, seriously. A LOT. ;)), and in doing so, often come across individuals who are doing an incredibly awesome job. I sometimes send off a little personal e-mail to thank them, but this is an attempt to be a little more public with the praise, and to help draw some more attention to these folks and their efforts. So, without further ado, meet catch.
catch is a web developer hailing from the United Kingdom, and has used Drupal since the 4.5.x era.
In order to help get familiar with some of the changes in 6.x, catch has taken it upon himself to go through the core issue queue and really help things clean up: marking duplicate and fixed issues as such, moving new features to the 7.x queue, and testing patches that need review, then marking things "ready to be committed" or "needs work" as appropriate. This is a tremendous contribution, as it helps the core development team to focus on the truly important issues, and his work will directly help Drupal 6 ship much sooner. And it's worth pointing out here that issue queue clean-up is an area that pretty much anyone with just a little spare time can help with.
I asked catch a few questions via e-mail, and this is what he had to say...
So, tell us a little about yourself.
I'm 26 and live in London with my wife and 20 month old daughter. I trained as a musician (saxophone), but improvised music doesn't pay, so have done various day jobs - music teaching, mental health support work, selling plastic trays etc since I graduated in 2001. I just started doing web development for money the past year or so and it's been my day job since the summer.
How'd you get your start with Drupal?
I tried out a few different CMSes before finding Drupal. The first dynamic site I built was a London gig listings site with postnuke/phpbb around 2002-3. Errrgh postnuke...
Then I joined the editorial group at my website in 2005 which was using some static html with php includes along with geeklog, wordpress, phpbb and gallery. We wanted to open a new section up for a document library, and chose Drupal because of the taxonomy system. Since we didn't really know what we were doing, and we had about 6 CMSes to maintain, we ended up with three of them hacked by a politically motivated script kiddie early last year. Decided it was time to ditch phpbb and others after that, and began to import everything into Drupal. Drupal could handle all the things we were doing with six seperate applications, and meant we could have a more integrated (and secure) site, and one that was endlessly extensible. This process forced me to get to grips with what I was actually doing a bit more, working on the command line, figuring out database import scripts etc. With about 6-7,000 articles spread across those systems + discussion forums with about 500 active and demanding users, it was a lot of work to move everything over (much of it manually) considering we're all unpaid volunteers doing the site in our spare time. But it allowed me to go up a steep and broad learning curve pretty quickly, and discovering cck and views at 4.7 stage meant we've not had to re-do too much since then. I'd had such bad experiences with big monolithic modules and third party integration that The Drupal WayTM became very comfortable early on.
What motivated you to start your amazing work on the issue queue?
Issue #6162: #new links don't work on paged threads.
We had people starting threads on our site about once a week for the first few months saying "why doesn't jump to last post work any more?", just what you need when you're tring to deal with a 256MB VPS crashing every day or so. This along with a few similar issues (mainly forum/comment based) led me to try to write a forum topic on drupal.org to bring some of the various forum issues/modules/snippets together in one place (to counter some of the "Drupal forums suck, can you write a vbulletin bridge instead" posts). Having done this, very little happened with the issues I wanted fixing, although people seemed to find the co-ordination of information useful, so I started reading through the issues I found to see why they weren't getting attention. One of our forum users got so fed up with "jump to last post" he wrote a fix for us himself which we kept hacking core with between 4.7.x and 5.x. This got committed to D6 about three months ago when I eventually rolled it into a patch, closing a three year old issue. After that, I realised my time was much better spent in the issue queue than continually re-applying hacks to core every upgrade or doing trial and error apache optimisation. I also realised that half the stuff on my wishlist had been flagged and worked on by other people more clever than me, but loads of good code wasn't getting into core for lack of eyes on it, or simply someone to check it doesn't break anything. The close call with pwolanin's book module improvements and the demise of the deletion API drove this home quite a bit more. This combined with Wim Leers' pleading for reviews on drupal lookup path optimization, an issue I actually helped with a bit, made me realise how fragile the process of getting things into core really is, and how much good code is going to waste from lack of reviews, or duplication due to the sheer volume of issues being worked on.
How do you think we could help engage more people to take on this important work as well?
The queues are pretty daunting when you first look at them. There's hundreds of patches waiting for D6 even at beta2 stage, two weeks ago there were over 300 patches to review (now down to 164, w00t!), some issues are three years old, referencing 2-3 other issues, others are one line fixes that can be reviewed and committed in a matter of minutes. The way I've approached this in the past few weeks is the premise that all patches either need work, are ready to be committed, or should be left until the next version of Drupal opens up. Sometimes they need reviewing by a very small group of people who understand the issues in more depth than me, but that's not that often, even for complex issues like the search patch where towards the end it was just applying it and searching your site. If I can get 9/10 issues out of the review queue, one way or another, then whatever's left for review will get more attention simply because it's easier to find, things that need work might get worked on, and things that should be committed will get committed.
Unless you have a chunk of time, it can be quite hard to work out which issue to review with your 20 minutes or whatever. For me, I think the biggest improvement would be breaking the queues down into more descriptive, more manageable, smaller chunks. Patches that need re-rolling, patches that need benchmarking, patches that need someone to test the user interface out. Then people who want to concentrate on any of those things have maybe 20, 30 issues to worry about. There's a feature request against project for a free-tagging vocabulary on issue followups to make that easier. Also I think the community in general needs to understand that there are far less people reviewing patches than writing them, and most of the people reviewing patches are writing their own patches as well. People always come out of the woodwork every release announcement saying "why hasn't core got this", and that's unlikely to change. But there's also people trying to work things out in the wild of the support forums who could just do with a nudge towards the issue queue to get started contributing more effectively. My knowledge of php and mysql is pretty basic, but I don't even need that to review a lot of issues, once you've got a testing environment set up it's a very easy process. You also learn a lot as you review (practice your coding, understand the internals of drupal better, find out about cool new stuff in Drupal 6 before almost anyone else), and you can help quite big features go in without having to do very much of the work at all.
Anything else you'd like to add?
Review, more, patches, start now.
Incidentally, catch is also taking on some freelance work, if anyone's interested. ;)