Bug reporting in Ubuntu
I read glyphobet's blog, itemizing frustrations he's had reporting bugs to Ubuntu. While I've not had frustrating experiences reporting bugs to Ubuntu, I've reported bugs to a lot of different open source projects, and had more than a few closed in a way I wasn't happy with, so I can definitely sympathize. I hope in Ubuntu these sorts of experiences are the exception, but certainly there's always room to improve.
In my own experience at having bugs closed in ways I thought were inappropriate or incorrect, while I was initially angry about it, after reflecting I realized in each case it was really a consequence that I didn't understand that particular project's bug philosophy and had filed the bug in a way that didn't adhere to their guidelines.
In working on X.org for Ubuntu, I've handled a LOT of bug reports, and while I personally try to be very cognizant of handling the reports in a respectful way, I've seen a lot of basic mistakes that reporters make, that will likely make it hard to get the solution they're hoping for.
So, here's my advice on how to be a great Bug Reporter for Ubuntu:
1. Attach evidence of your problem. This is the most common important thing most bug reporters fail to do. For X.org, this means Xorg.0.log, lspci output, and so on. Photographs of the screen are good too. Anything with error messages is good. The more evidence, the better.
I can easily spend a full day a week going through bug reports and requesting better evidence for bugs. If users were more proactive in providing this info, it'd allow more energy to be focused towards finding solutions.
2. Choose a good title. An ambiguous title, like "X looks wrong" is going to accumulate a lot of (false) me-too's, which will both distract from getting *your* issue solved, and give false hope to the me-too'ers who don't actually have the same issue.
Launchpad's bug reporting interface tries to match a new report to existing ones, and it seems to give a lot of weight to the title. If your title is too generic, launchpad may inadvertently direct people to your bug, when
3. Give clear steps to reproduce the issue. Some of our most frustrating X bugs get titled something like, "X crashes randomly after some period of time." These are next to impossible to investigate, and usually aren't worth reporting upstream.
4. If you have a crash or lockup, attach a backtrace. Yes, backtraces can sometimes be a lot of work to get, but honestly it's rare that action can be taken on a crash bug until we know where in the code the crash is happening; a backtrace (usually) indicates this.
5. Don't expect Ubuntu will fix the bug. Ubuntu has a *huge* userbase and while we have a lot of good developers, the rate of bug reporting far, far exceeds our bug fixing abilities. Even a perfectly reported bug can often take several days or a week to create a solution for; for a popular Ubuntu package (xserver let's say) it wouldn't be unusual to have a dozen or two new reports come in over that same time period.
So, in many cases, the best outcome you can hope for is that your bug gets reported upstream. You can often have faster results by shortcutting this process and forwarding your report upstream yourself. Be aware though that upstream projects may have stricter (or different) bug reporting guidelines.
Sometimes bugs really are specific to Ubuntu, and it's these bugs that Ubuntu engineers try to prioritize their time for; obviously if the issue is our fault, we need to put priority into fixing it. We'll also give priority to bugs that are severe and/or widespread, or that look relatively easy to fix. The former is usually out of your hands, but the latter you can do something about:
6. Make your bug easier to fix. Even if you've followed all the above steps, you still may not see progress on your bug, but that's not the end of the story! If you have time and patience (or are sufficiently driven by the frustrations), there's several things you can do to help improve your bug's chances:
a) Vary some parameters. Try reproducing it on different hardware, or different OS's, or different Ubuntu releases. Try reproducing the issue several different ways.
b) Find dupes. Often other people will report the same issue, but maybe in different ways. Also look upstream and at Debian's bug tracker. Dupe bugs are valuable because the other reporters often have interesting insights. As they say, "Many eyes make bugs shallow."
c) Seek out patches. If you find a fix somewhere - forums, upstream bug trackers, casual acquaintances, whatever - these can often turn the bug into very low hanging fruit. The developer can then just doublecheck that the patch won't cause issues for other people. Even negative findings can provide valuable clues.
d) Be active with your bug. Many bugs cannot be reproduced by the developer, so they rely heavily on the reporter to carry out experiments, test patches, and so on. If you don't think you have the technical skill to do this, say so and ask for pointers or directions.