As a (relatively) long time Ubuntu user, occasional bug reporter and support analyst, I often deal with bug reporting and I feel your pain about bug reporting, Matt. This happens in many other free software projects, but I think Ubuntu’s popularity gives its problems more exposure, an opportunity to refine the process and maybe inspire others to learn from its mistakes and success.

Generally speaking it’s always nice if you can dedicate a few dozen minutes (around an hour I would say) to familiarize yourself with how bugs are reported in the project you’re participating with. In Ubuntu it’s the Bug Squad team – perhaps even join it. I view Bug Squad members as the little bee-workers that are front-line organizers and helpers in the fight against bugs.

Think about it. An hour or so is not that much to dedicate to learning and understanding how your contributions will (or not) affect Ubuntu. It will also give you tools and guidance to become helpful and efficient in any bug reporting. I am not saying everyone should join! But those of you who don’t join need to at least understand how a bug report is treated on the receiving end.

I’d like to contribute 10 things to avoid and 10 things you can do if you want to increase the chances of getting good results from bug reporting (meaning a fix or solution). Some of them come from the Best Bug Reporting Practices wiki page.

1. Look for existing bug reports that match your problem. It saves a tremendous amount of time when several people do this. It helps confirming a bug and tying loose ends 🙂 Checking upstream and linking those is very nice too!
2. When filing a new bug, mention the ID’s of all bugs that sound similar. use « Bug #XXX », this provides an automatic link. Someone can dupe them together later.
3. Add missing data (including video, YES VIDEO, screen captures, logs) to an existing bug. In some cases more is better.
4. Provide context. Consider what is unique about your system, and mention it. Is it brand new out of the assembly line ? Did it stay overnight outside at -40C ? Is your music collection that fails to import in Rhythmbox 40000 files big ? Did you just reinstall ?
5. Itemize the exact steps that result in the issue. Can you reproduce it at will? This is perhaps the single most important thing. If no one can reproduce your bug, chances are no one will be able to fix it. Providing clear steps dramatically helps.
6. Follow up on your bugs from time to time, even if they seem ignored. Kindly ask for a follow-up if/when appropriate.
7. Report if the issue goes away or remains when new Ubuntu’s come out.
8. Once you’ve reported a bug, or if you have a few that are important to you, give them visibility. Go to forums, mailing lists, or post them in your blog. Not everyone reads bug reports or knows an issue they have is being worked on.
9. Use IRC. Live chatting with developers on #ubuntu-bugs or #ubuntu-devel and asking a few questions while writing your bug report may help getting better information (like which package the bug should belong to).
10. Get confirmation (or rejection) as soon as possible. Befriend a developer, expose your bugs, use whatever means to have other people confirm or reject your bugs. Be proactive if you want your bug reports to get some « traction ».

Here are my don’ts:

1. Do not assume your bug report is more important because you’ve put several hours thouroughly detailing it. I know because I have done that. In many cases I see such reports as a documentation available to others, so they don’t repeat my own mistakes.
2. Don’t be rude. Whatever the frustration, it’s not helpful to the bug’s resolution. I personally find this is the hardest to do 🙂 When in doubt, read again the Ubuntu Code of Conduct, take a few minutes before ranting.
3. Don’t cite external links with lenghty discussions – unless you summarize them in one or two sentence. – this multiplies exponentially the time required to assess a bug’s status, importance, etc.
4. Do not assume « they must already know about this » – no one does. Making assumptions only adds delays while clarifications are obtained.
5. Don’t add « me too » responses, unless you are giving more details that actually help confirming a bug in its early reporting. It wastes everyone’s time when reviewing a bug (not to mention emails generated).
6. Don’t post bugs with only a brief description of the problem. « XXXX doesn’t work » will get rejected or will expire. A model number for hardware by itself is not enough detail.
7. Don’t assume others will « just know » how the bug occurs. Sometimes non-technical details (like « the wireless connection always drop when I pickup my wireless phone ») provide important context.
8. Don’t fire and forget. Abandoned bugs rarely get fixed. If you are not willing / able to subscribe to your own bug reports and provide feedback, additional information, and even ultimately test possible solutions, make it clear in the bug report or don’t file it.
9. Don’t post bug reports in other languages than english. This may seem obvious but when you install Ubuntu for someone that will be using it in any other language than english, automatic bug reporting may kick in and give the false impression any reports can be filed in another language. Educate your non-English speaking Ubuntu « customers » about this.
10. Don’t assume every issue is critical. Between fixing a screensaver that crashes Ubuntu (easily worked around) or fixing a RAID issue that affects all server installs, what do you think should get more attention ? Importance is relative. Not everyone’s emergency is someone else’s too.
11. EXTRA: Don’t ignore guidelines and procedure. If you know a rule, don’t ask for exceptions!

Last but not least, if your bug concerns business needs and is stopping your business or your customer or any commercial activity, consider actually paying a developer or company to look into it. Part of Canonical’s support services includes bug escalation but there are many other ways to « financially speed up » a bug’s resolution. Citing business concerns in Launchpad to speed up a bug’s resolution is not what I mean here, but actually paying someone to go through the community process for you or your company / organization.

If anyone has other tips to contribute, I’d love to hear them. I am far from a bug reporting expert so I’d love to learn any new tricks and tips here 🙂