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.
- 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!
- 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.
- Add missing data (including video, YES VIDEO, screen captures, logs) to an existing bug. In some cases more is better.
- 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 ?
- 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.
- Follow up on your bugs from time to time, even if they seem ignored. Kindly ask for a follow-up if/when appropriate.
- Report if the issue goes away or remains when new Ubuntu’s come out.
- 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.
- 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).
- 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:
- 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.
- 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.
- 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.
- Do not assume « they must already know about this » – no one does. Making assumptions only adds delays while clarifications are obtained.
- 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).
- 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.
- 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.
- 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.
- 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.
- 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.
- 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 🙂
> 9. Dont post bug reports in other languages than english.
Hmmm, I do not agree with this piece of advice. Should people who do not speak English be deprived from submitting their own bug? It’s a gross injustice in my opinion. Those who do no speak English, or even those who are not native English speakers have become second class citizen. Ubuntu is translated in many languages for good reasons: a minority of people speak English.
Granted, English is the de-facto language in the open source community, so bugs have most certainly more chance of being fixed if submitted in English. However, we should not frown at those who can’t submit in English.
Maybe we should look for volunteers to tranlate any relevent material and merge it into the english bug reports in accordance with Do #3.
This is one of the greatest article.Keep up the good work. We all come across the situation of reporting bugs! I hope this article will save a lot of time of all the volunteers!
https://blueprints.edge.launchpad.net/malone/+spec/malone-me-too
> Hmmm, I do not agree with this piece of
> advice. Should people who do not speak
> English be deprived from submitting
> their own bug? Its a gross injustice
> in my opinion.
What are you smoking?! The reason for this is, pretty obviously and not really surprisingly, that English is the common language all developers (i.e. people who *read* the bugs and fix them) speak. Don’t be idiot, if you file bugs in Esperanto, nobody will understand them.
@fook: no need for name calling eh ? 🙂
@dominiko: actually nothing prevents you from filing bugs in any language. You’ll only be waiting much longer between someone translating that, and going back and forth in translation we’ll loose details and other information. Not to mention developers will skip the bug report and work in other english only reports.
Maybe local teams could help in that kind of situation, where one member of the team can relay the information. But following up in any other language than english will probably be inpractical.
English is a good communication form, most of the world speaks english. Don’t be selfish.
Ubuntu bug developement actually keeps new people from coming to open source. I love the idea of open source but when I changed to Ubuntu from XP I lost two programs that I absolutely need to run my business. So I have to go back to XP.
While there is no arguing with the 10 steps that you laid out, I’m sorry but, I strongly disagree with the tone of your article. It suggests that the problem with Ubuntu’s bug fixing is because of the end user/bug submitters and that is absolutely incorrect. In fact it is insulting!
The fact is that Ubuntu has a major problem in its bug fixing culture. As described in the linked blog article, it certainly seems that they are more interested in fiddling with bug metrics than actually fixing the bugs themselves.
I will provide one of many other anecdotal examples of Ubuntu bug fixing madness. This critical Ubuntu bug and its half dozen similar/duplicate bugs languished for months without a fix being released. It remained unfixed even though upstream Debian had fixed it months before. Months!
Now it’s all well and good to claim that open source projects are not mandated to fix things in a certain amount of time but, Ubuntu is different. Ubuntu is managed and promoted by a commercial company which, in my opinion, obligates them to do a better or more professional job. Debian, which is entirely community based without the corporate backing that Ubuntu has is doing a far better job with bug management.
There is a problem with Ubuntu and implying that it is because bug reporters aren’t submitting the bugs correctly only furthers the problem.
@fook, maybe you should learn to read what the quoted author really said. Once you did this, come back and discuss the basic notion about those users who do not speak/can write english and thus would not be heard.
>English is a good communication
>form, most of the world speaks
>english. Dont be selfish.
Only 5% of the world population is native english speaker. One in four can understand, maybe speak.
Europe is probably one of the big markets for Ubuntu. But if you ask someone in Germany, France or Spain (just to cite some places I know) to file a bug in English, I think that very likely they will not do it. At least is the impression I have after 33 years living in Europe.
So I guess those of us who can speak several languages could be helpful in this situation…
If there was an easy way to record videos from those buggy situations, we would need no words. Just click record, show the problem, and upload automatically the video. Of course it’s never as easy as that, but implementing this feature in any operating system could help developers of any kind see what’s going on.
All those points are valid, but there are quite a few bugs on Ubuntu that have remained open for months (Like the ipwXXXX drivers locking up the entire computer or dmcrypt loading all its libs into /usr/lib, genius), and have been fixed in other distributions.
There is some sort of laziness or hatred/elitism towards certain brands and software with Ubuntu devs preventing some fixed bugs from being fixed in Ubuntu.
I understand the need for good bug reports. However, the responsibility for getting good bug reports lies with Ubuntu (or whoever is taking them).
Very few people, other than those generally classified as losers, will spend « several hours » learning how to file a bug report. Very few users will put in the kind of time necessary to satisfy the Ubuntu bug pharisees.
This reminds me of Eric Raymond’s rules for smart posting. It had one effect: it drove tens of thousands of users back into the arms of Microsoft. One RTFM and they were gone.
The bug reporting infrastructure stinks, to put it mildly. Until that is resolved, bug reports will stink too.
The biggest problem with this is the attitude that « I’m doing you a favor by taking your bug report. » It’s just not realistic to think a recent Windows convert will spend big chunks of time learning how to tell someone their product doesn’t work. If your time is worth $50/hour, that’s $200 of opportunity cost to spend 4 hours figuring out how to tell someone else that their program doesn’t work. Especially when the program _doesn’t work_ which is why there is a bug, so they can’t use the program the way they want to even if they report the bug to the satisfaction of the developer.
Sorry, wrong strategy for the open source community to pursue. The right strategy is to figure out a 5-minute bug reporting procedure that is relatively pain-free.
Ubuntu got to the top quickly because it was extremely focused on providing a small, complete desktop distribution with only one of each kind of program. It needs to rededicate itself to that goal.
The developers need to focus on bugs which affect the software installed by default. There are way too many critical bugs in default applications while people are trying to add new, fancy features.
6.06LTS took two extra months to get out the door because Canonical was serious about squashing those last few bugs. I don’t trust them to do that for 8.04LTS.
As a regular bug submitter, I fully agree with article, and very strongly disagree with some of comments. I see people get very emotional when nice open source app suddenly breaks or doesn’t work as intended – and rightly so. But such people rarely know how to report bug. So I have addition to a list – if you are not sure that you can deal with report, go to channel #ubuntu-dev or #ubuntu and ask for help. If you will provide details, bug will be submitted by others and you will be added as subscriber – just in case if they will need new data.
In fact, IMO, Ubuntu bug system is one of the best, because it has regular people who check and triage bugs. No other project does that. It also keeps in check bigger picture.
@eric, ok smart mouth, provide any details of ideal bug reporting system who would collect all intelligent data without user intervention, will describe steps how user broke app, etc.
Problem lies there that most bugs are two types – either they are extremely popular and already known (therefore making bug submitting dublication) or very corner cases in which 5 minute bug report is simply impossible.
@Daeng Bo: but they already does! You understand what means official support from Cannonical, don’t you? In fact, I suggest you to take a look to 8.04LTS alpha, because it hasn’t crashed, it is stable already know, feature freeze is already active (so it means three months to fix all critical bugs), so I think it will end rather good for Ubuntu.
@Yeah: no, simply there are not enough people to review and submit patches in all software. I have read your bug example, and I don’t think it is so very important, at least after provided fix which is available from gutsy-updates. Of course, people which are affected by this bug won’t say so.
I just don’t like that people bash bug reporting and fixing, because I doubt they imagine what amount of work all this requires. People who triage and test bugs aren’t expert on everything, so they have to wait when that and that bug will be fixed in mainstream. Sometimes, it is impossible to provide a bug fix due of restrains of distro (no major updates after release, only small bugfixes or security updates).
@sorry.no! It is noteworthy that Debian and Ubuntu are different cultures with dissimilar goals. Ubuntu is primarily oriented toward usability and features added to Debian testing. In contrast Debian’s primary goals seem to be security and stability. So the Debian culture is far more bug oriented.
Your guidelines are very helpful, and in my opinion should become a sticky note in the forums.
Thanks.
cmn