Claiming victory – the first Wine Bug Day

I want to help Wine development in any way I can.  Sometimes this means putting on pants and discussing donating money to Wine with serious people.   Sometimes it means using my charming personality to persuade promising programmers into becoming Wine developers.  Sometimes, however, it’s about something larger: helping existing developers work more efficiently.

Engaging the community

While Wine has over 2 million users, we’re not particularly good at marshaling the community towards helping out.  The Application Database, for instance, contains test reports that are frequently out of date and not particularly useful.

Getting good involvement from the community is not a trivial task.  Users need some level of expertise and confidence before they can offer useful help to others.  People need to suffer through reading the same question over and over again in mailing lists and forums before they’ll volunteer to write the answer into actual documentation.

This means the most important tools are those that make it easier for community members to build that confidence and contribute.  We used to require users to submit patches to update the FAQ.  This meant they had to grow neckbeards, put on wizard hats, and use terminal commands just to edit a text document.  Unsurprisingly, the FAQ quickly became so out of date that it was outright harmful to read.

After some nagging, the FAQ was eventually moved from the source tree into a wiki.  The barrier to contributing went from learning a version control system to clicking an edit button on a web page.  After years of neglect, the FAQ became genuinely useful within a single month.

I want to give Wine coders more time to, well, code.  That means less time wasted doing all the other annoying tasks in life.  Although I can’t do their laundry or clean their bathrooms over the internet, I can help them spend less time sifting through Bugzilla.

Is it worth triaging bugs?

Wine, like all reasonable projects, is utterly swimming in bug reports.  Fortunately, we’re not quite drowning in them – while thousands remain open, we’re triaging them at about the same rate as new ones are being added, barely keeping our head above water.

Let’s think for a moment about what a developer gets from a bug tracker:

• If something is broken, they learn about it so they can solve it later
• Developers can collaborate with eachother on a solution
• If they need motivation they can feel happy that actual users would appreciate a fix
• They can consider the difficulty and importance of different bugs to prioritize work

All this breaks down when there’s a ton of out of date or otherwise bad bug reports.  Instead of a useful tool, the bug tracker feels like an obstacle.  Eventually it ends up like graffiti in a big city: the problem becomes so huge that any individual effort spent fixing it feels like a waste.

Working together on a bug day

The idea of a bug day is to make it much easier for community members to triage bugs.  You’re all doing it together, so there’s less a feeling of solitude even if you’re alone in your parents’ basement.  If you’re unsure of something, you just ask someone in chat, building up a little confidence.  If you don’t have bugzilla permissions, someone else will set a bug’s status to fixed for you right there, keeping the energy up.  This makes the whole process actually kind of fun – so much so that people actually organize real life parties dedicated to bug triage.

That’s why bug days work – they help bugs get triaged in the same way that wikis help documents get written.  You see the collaboration and progress right before your eyes, especially when you pick a particular set of bugs as a target.  There’s an easily measured goal to start with, and everyone gets excited when the group hits 50 bugs for the first time.  This even works when the bugs are a relatively easy subset: for Wine’s first bug day I decided to only target bugs with free downloads that hadn’t been checked in over 7 months.

Claiming victory

To be honest, this bug day wasn’t very well planned.  I basically picked a day, threw together a forum thread and an email to the developer list, and then hoped for the best.  I didn’t even blog about it.  Somehow, amazingly, it was still an overwhelming success:

Our bug target search (bugs unchanged since January 1st with the download tag) started at 574 bugs.  Now it’s down to 508.  That’s 66 bugs that were either resolved, confirmed, or at least checked in on.

In the past two days there have been 30 bugs newly resolved.  By comparison, over the previous 2 weeks before then there were only 16 bugs resolved.

I’m definitely going to repeat it again and make this a regular thing.  The community really does help if you simply ask.