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.

Except, unfortunately, it wasn’t.  You see, some people at Ubuntu are worried about derivatives: those Ubuntu-based distributions that use our code but aren’t actually Ubuntu.  By putting a branded image in that derivatives have to remove, we make extra work for them.

So nothing happened.  For years.  We still had that ugly foot logo that had nothing to do with the game you were playing, and it was one of the first things users saw.  But it wasn’t just Gnometris – it was solitaire too.  Millions of hours of user time have been spent playing solitaire and staring at the ugly feet on the card backs.  People would boot the Ubuntu LiveCD and feel like our games came straight out of 1995.

This bothered me.  It was ugly, but even worse we were throwing away useful contributions.  How much other useful stuff might we be throwing out, or even worse not making in the first place?

Enter UDS

The Ubuntu Developer Summit is a fantastic place for brainstorming ideas.  You’re constantly surrounded by smart, passionate people.  People who want to work with you on any and all things Ubuntu, from the moment you walk out of your hotel room for breakfast to the late hour you finally trudge off to sleep.

I think the branding-ubuntu package was my idea.  I can never be sure, since I owe so much to the creative environment around me.  I shouldn’t offend anyone by taking credit though; as you’ll see, my original design was stupid.

The overall idea seemed solid: put Ubuntu-branded replacement artwork, generated by the community, into a single branding-ubuntu package.  Installing it would change the artwork, removing it would leave everything as before.

The original design required each branded application to have a small patch causing it to look for the branded artwork first (and prefer it.)  This required modifying every program that we wanted to brand.  All I had to do was dump a bunch of artwork in some folder, and then hope other people would change their applications to take advantage of it.  Trivial for me, work for them – perhaps it wasn’t so stupid after all.

Community Leadership

Other than my three year old Gnometris background, I didn’t have any actual artwork to put into the package.  We weren’t even installing Gnometris by default anymore.  I made the package anyway.  Even though it didn’t do anything, I decided to advertise and fish for community help.  If I built it, perhaps they would come.

I wrote a few emails to our developer lists, rubbed a few shoulders on IRC, and reminded some of the people who mentioned it was a great idea at UDS.  Importantly, I took charge, making it clear that all an artist had to do was make something nice and I’d handle including it personally.

Within a manner of days I had new, branded artwork for every game we ship.  Now I had a whole lot of artwork, courtesy of MadsRH.  The screenshots from a manual install were incredible – that blue foot was gone for good.  All it took was a little initiative.

Unfortunately, those patches to use the branding hadn’t yet been written, and the upstream makers of Solitaire didn’t really want to do it.  In retrospect this is completely understandable – it was their branding we were replacing, and it wasn’t clear to them why we weren’t just patching things on our end.  Why should they care about our derivative worries?

The Real Solution

The real solution, of course, meant more work for me – but work that would actually get done.  The branding package now renames existing artwork files and replaces them with symbolic links to its own (using some fancy shell scripts and the very obscure dpkg-diversions command).  In short, it works elegantly.

So, now I’ve got yet another package under my stewardship.  I started off just maintaining Wine five years ago, but now, in true open source fashion, I’ve been applying myself throughout the entire distro.  Sometimes people refer to this as “scratching your own itches”, but in truth I don’t really play solitaire or use Wine that much.  They’re not my itches – they’re the itches of millions of users.  Those are real people, and that alone is reason enough for me to make things even just a tiny bit better.

Human responses

Over the past few months, at least five separate people have reached out to me personally asking about specific ways they could help. I’m happy to answer, of course, but this tells me that it’s not at all obvious for them to figure out on their own. Likely, there’s five more who never emailed me since it was too much of a hassle to talk to an internet stranger, even a blogger who IMs more than a 13 year old girl.

What’s needed, then, is just a simple encouragement of human interaction. The open source community is a strange concept to newcomers, even the computer-savvy. You really can just dive right in and start offering help wherever you’re useful, and developers will just treat it like it’s the most natural thing. Maybe you’re from another project, or deploying the software in a business, or just bored around the house. There’s no such thing as an imposter in open source.

Many people who aren’t used to this kind of openness find it intimidating – there are too many people, so it’s not obvious who to go to for help getting started. We try to have mentoring programs and the like, but these are for people who want to be serious developers solving big problems. Small problems don’t need serious developers – they need a serious amount of small help.

Practical things for getting small help

At the Developer Summit, we discussed the idea of using more helpful bug tags to help contributors find where they can help. Our goal isn’t to sort half a million launchpad bugs into forty tiers of type, importance, and difficulty – our goal is to get them fixed.

So, here are the brand new bug tags, based on a simple discussion from the developer summit:

• needs-artwork – for bugs that need new art
• needs-sound – for bugs that need new sound
• needs-coding – for bugs that need actual code
• needs-design – for bugs that need UI design

Most bug trackers don’t really use tags like this because the system is obvious – if you’re looking at Wine’s bugzilla, then pretty much every bug in there really could be tagged “needs-coding-c”. Launchpad is different: we’ve got a whole mess of bugs, and half of them aren’t even in the code.

Now we’ve got a real answer to the question “I want to help, what can I do?” We just tag some bugs and say click the link: Launchpad will instantly tell them dozens of places where they’ll be useful. That’s important, as they’ll not only be able to help, but they’ll also see that they can fill a real need and feel good about themselves. Make contributing simple and rewarding, and users will do so eagerly.