I know there was some talk a while back about having BugDays on Drupal. I don't know if that's still the plan, but I wanted to get the ball rolling and discuss why and how it would be organized so we can get something started sooner than later. I was, for a short while, running bug days for CivicSpace until we went out of our way to move all of our code to drupal.org where the volume of feedback and patch submissions were much greater. What's written below are simply my thoughts around it. I'm open to feedback on these ideas, though ultimately, I would like to leave the details up to whoever ends up as the designated coordinator(s) for a Bug Day.
Why have a bug day?
---
Well, obviously, the Drupal project has been growing and growing. As such, we need to do something towards the end of organizing and fixing our bugs in a way that is efficient and optimal, while keeping in mind that this is mostly a volunteer effort (as most Drupal coders work on a volunteer basis).
In my own view, Drupal core is relatively stable and already has enough talented programmers scrutinizing the code base. What I personally would like to see is more attention being given to the contributed modules. Contributed modules often have a problem with correctly making use of the Drupal API and are more privy to slacking on code conventions. This is expected since a CMS engine as flexible and fast as Drupal will inevitably pose a steep learning curve to those that want to add new functionality. And often, the rush to add new features is understandably more urgent to the implementor than the desire to be vigilant about API usage and coding standards. However, if Drupal is going to take over the world, it will be through its rich variety of contributed modules. Most of the CMSs out there offer the same features that Drupal core offers; the magic, in my opinion, is in the contributions. However, the contributions need to be just as stable as the core. Otherwise, the projects page, which lists 160 or so modules, will be a deceivingly long list.
Where, when, how?
---
I took a quick look around the web to see how other projects tend to manager their bugs and bug days. Obviously, we don't want to be a carbon copy of everyone else's bug day, but should start with practices that already seem to work before we try anything new. I found a few things in common among the Bug Days for other projects:
(1) Fixing vs. Triaging:
One thing I noticed is that what most people considered to be their 'Bug Day' was really a day set aside to 'triage' bugs as opposed to fix bugs. 'Triaging' just means categorizing types and severity of bugs. It also involves adding more detail to bug reports as well closing duplicates and re-classifying certain bugs as support requests. Another possible reason for making a Bug Day simply a day of triaging instead of fixing is that fixing a particular bug might take more than a day. Also, a coder that can understand the bug might not be available on the same day.
(2) Seperate IRC Channel:
A lot of the Bug Days use a seperate IRC channel where users and coders categorize and assign bugs. Depending on the size of a project, this will often be a channel seperate from the main developer channel. In Drupal's case, I think #drupal is
sufficient for hosting any necessary live coordination of an effort. Take it to the coders instead of making them go to another IRC channel.
(3) A seperate e-mail list:
Some of the projects use a seperate mailing list for Bug Days. I think we have enough mailing lists.
(3) An IRC bot:
I've noticed that the Gentoo bug channel (as well as another that I can't remember at the moment) have an IRC bot that is directly integrated with Bugzilla. The bot will typically announce changes to the issue queue as they happen and offer a
command that will provide a summary of a report in the IRC. This comes in handy if the IRC channel is being used to discuss and assign bugs. In our case, it could potentially be tied into our (contributed) project module for tracking bugs. I'm sure mozillaman (aka Robin Monks) can speak to this more as he's had experience with this setup for Mozilla and is familiar with the DrupalBot in #drupal.
(4) A special list:
Some of the Bug Days create a list simply by providing a URL with GET parameters that filter the bugs from the relevant issue tracker's search function in a certain way. However, the more successful ones seem to provide a manually composed list of
selected bugs, breaking them down into categories, so potential squashers can easily browse to what they know.
(5) Frequency:
Most projects seem to run a Bug Day once every two weeks or once every month. I'd say we should do the same. If we tried to do this weekly, we'd probably spend more time organizing than we would triaging and fixing.
In anycase, this is what I've gathered. I'd be interested in seeing what others have to say to any part of this. The ultimate goal is to make it easier for coders to get in front of bugs they can and want to fix, to reduce the time we spend getting bugs in front of them, and to reduce the time they spend finding them.
Resources (please feel free to add to this list)
---
Gentoo -- http://bugday.gentoo.org
Ubuntu -- https://wiki.ubuntu.com/HelpingWithBugs
Mozilla -- http://bugday.moznetwork.org
Linuxbase -- http://www.linuxbase.org/LSBWiki/BugDay
Plone -- http://plone.org/development/info/bugday
Gnome -- http://developer.gnome.org/projects/bugsquad/triage/faq.html#ll
Zwiki -- http://zwiki.org/BugDay
Python -- http://wiki.python.org/moin/PythonBugDay
