bugs.kde.org

I work with bugs.kde.org nearly every single day.

Most people who report bugs on it hardly ever visit it, and that's not a bad thing.

Some people who do end up there are frustrated due to some problem they ran into and so show up a little less than happy. Most are congenial, however, which is nice.

Unfortunately, there's still that familiarity gap. I have built up over the years a set of internal expectations around handling the bug system that I know are completely non-obvious to anyone who doesn't use bugs.kde.org often .. which is most of our reporters .. which leads to frustration. Everyone couple years I blog about this frustration. This one of those blogs.

Sometimes I honestly think a "bugs.kde.org driver's test" should be a prerequisite to using the system. It would go miles to improving the quality of the reports. In lieu of that, here are some quicky notes on handling bugs.kde.org:

• Always include the version of KDE you are using. If you build from svn, then include the svn revision #. Otherwise, `kde4-config --version` is perfect.


• If reporting a crash, provide a detailed description of what led to the crash. If reporting a functionality bug, describe the steps in detail needed to reproduce the problem. If you don't know, just describe as much as you can about what you or the machine was doing at the time. These descriptions help us replicate your experience which is critical to solving many reported problems.


• If you are reporting a crash, always include a backtrace. If it has lots of "unknown symbols" in it, though, it's not likely to be very useful and your description of how to reproduce will be even more important. However, first consider reading this how-to on creating nice backtraces and get a realy good backtrace for the report.


• Do not upload backtraces as attachments to reports! Instead paste them into a comment. This lets us easily search the database for similar backtraces. It's easy to search through comments in Bugzilla, not so much so through random attachments.


• If the bug is rendering related, include what the graphics hardware and driver version is. It may not be relevant, but it often is and will save a "what's your graphics hardware?" roundtrip question.


• If the bug has a visual manifestation (e.g. you can see the bug itself or symptoms of it somewhere on the screen) consider taking a screenshot of it and attaching it to the report. Screenshots are often very, very useful to understanding bug reports. Pictures and a thousand words and all that.


• If you can't reproduce the bug after a while, let us know. That's useful information.


• If we ask for more information, try and respond as soon as you can. Some bugs are easier to fix at certain times than others, for various reasons. Helping us by being attentive is much appreciated. If you can't get to it right away, or if you feel the answer you have isn't a good one (e.g. you tried what was requested, and nothing happened) still report back with either a "I'll get to it when I can" or "I tried it and got nothing useful back". At least this way we know you're still there.


• Do not post to random bug reports unless your problem is the exact one in the original report. If you have a crash and your backtrace does not look identical at the top of it to the one in the report, do not add it to an existing report. If you have a similar sounding but not identical problem, do not add it to an existing report. File new reports. Bugzilla lets us merge reports, but it does not let us take a single comment and break it out into its own report. I wish it did, but it doesn't. Yes, this is a shortcoming in Bugzilla, but it's one we have to live with. This means that if you just pile in new bugs into old reports, we end up with reports that are completely unmanageable. Eventually, I just end up closing those kinds of ruined reports and make everyone file new ones.


• Which leads to: one problem per report. Yes, Bugzilla is not the fastest tool to use and so it can be tempting to just pile in 2, 3, 5 or sometimes even more issues into the same report. Don't. It becomes very hard to track which issues are fixed and which aren't. Again, this is mostly due to shortcomings in Bugzilla, but it's the reality we deal with. File separate reports for separate issues; and yes, even if it's two different issues on the same topic. ;)


• Whenever you comment on a bug, the assignee(s) and the people on the CC list get an email with your comment in it ... even if the report is closed. So feel free to add comments to reports, someone somewhere will still get a notice of them.


• Fixes will not appear immediately on your computer. You will need to wait until you update your installation to a version that contains that fix. Depending on when the fix is made and how you install KDE, this can even be many months time. This may sound like an obvious item, but many people seem rather surprised when I mark something as fixed with a commit to svn but the problem is still there on their computer.


• Describe your problems thoroughly, but don't get too clever unless you've actually read the code. Way too often I get reports where the person has a pet theory about why something is happening and unfortunately the theory is dead wrong. At best it's just a waste of my time reading that part of the report, but more often it ends up confusing the report with some misinformation and worst case (which happens too often) the reporter gets so caught up in their idea of why the bug is happening that they end up describing that theoretical problem as opposed to what is actually happening. This risks confusing the bug triager, and often just means a long series of back and forth questions. If at all in doubt, just describe the problem as it manifests itself as thoroughly as possible. Leave the root-cause sleuthing to those with the code in front of them.


• You don't have to suggest a solution. It is perfectly Ok to say "This doesn't work for me." and leave it at that. If there is a preferred way you'd like to see it happen, describe it in those terms: "I would prefer if ..". But as the reporter you don't have to come up with a solution.


• I hate the term "wishlist" because it makes it sound like something you'd like to have but probably won't get. I far prefer the term "feature request" because that's what it really is, and "feature request" lacks all the implications of "wishlist". Some people get really annoyed when I mark their report as "wishlist" and in one sense I don't blame them; if you didn't know any better it might sound like your report has just been brushed off. That's not the case, however: if the request is for a new feature or new functionality, as opposed to fixing existing functionality, it's a feature request not a defect report.


• Don't bother overstating the severity of your bug. It won't fool anyone. Seriously. =)


• Don't bother linking to your favourite bug report from your blog, on web forums, on irc, etc hoping people will vote for it. When I see a bunch of people randomly showing up to vote on a report, I assume this is what has happened and ignore those votes. Such vote canvasing only distorts the statistical distribution of voting on bugs.kde.org and makes it impossible to distinguish between reports people actually, really want fixed and ones that someone has just done an effective job of campaigning for in online forums. ;) In general, I put far more weight behind how many duplicates a report has than votes.


• When it comes to feature requests, a judgment call is often required. That call belongs to the person(s) designing the software. If they decide against a feature, don't belabor the point by endlessly trying to convince them or getting angry with them. It doesn't help anything.


• Saying thank-you even once makes up for 10 mistakes made elsewhere. It's really encouraging when a reporter is civil, cordial and says "thanks" when the fix goes in. Dealing with reports on bugzilla is, quite frankly, not the sexiest thing in the world to do, so anything that makes it go a little easier and nicer helps.

Probably not an exhaustive list, but there you go. Hopefully something in that list is useful to someone out there at some point in the future. =)