| The roads I take... | Ein neues Logo für die UME! >>

effective work with a bug reporting system

Again and again I stumble over people who seemingly don't understand how a bug reporting system is supposed to be used - usually that's Mozilla's Bugzilla in my case.

Those systems can work very well for reporting and working on bugs, and even though it could be improved (yes, all improvements I'd like are filed as bugs themselves), Bugzilla has grown into a really good such system over the years. To be honest, I've never professionally studied such technologies, and Bugzilla is the only one I know really well, but when you're working with it long enough and think about it, you begin to understand what this is all about.

One common mistake people are making is to go into a bug report that already has 50 or more comments and is pretty lengthy, and then they request some detail change in some part of the work that has already been done, reviewed and landed there. A recent comment in the "new SeaMonkey theme" bug doing exactly that is what leads me to write this blog entry. The correct solution to deal with such issues caused by a different bug (esp. if that one is a lengthy report already) is to file a new "followup" bug that covers exactly that one detailed issue you're seeing and mark this new bug dependent on the original one. Leaving a comment in the original bug can also help to get attention to the new issue, but that comment shouldn't be more than "I found a problem with X caused by this checkin, see bug XXXXXX" (Bugzilla is intelligent enough to link your mentioning of "bug XXXXXX" to the actual bug report).

Another common mistake is to add comments to the bug that don't add anything that wasn't already said there, esp. comments that just tell "I'm seeing this too" or "I want this fixed as well" or even "Adding myself to the CC list". "Me too" is only useful if you tell that you're seeing this on a configuration where it wasn't clear before that it is affected by the bug. If developers already know the cause for the problem or are convinced that this should be fixed, a "me too" comment just wastes their time - they need to read it and get no new information from that read, while they could use the same time to already actually work on a fix. You're probably distracting other people from work with such comments, keep that in mind.

I even believe that discussion of how some implementation should work in concept is usually wrong for a bug report. Bug reports should focus on explaining what exactly is the issue, finding out its root cause, and the actual fix (along with reviews of that fix). That's even true for feature requests. If the design of such a feature is unclear, this should be discussed in some place that allows to do this more in a real discussion style, allows easy editing of drafts, etc. Use a newsgroup, a wiki page, or both, or whatever fits this issue, link that from the bug, and come back to the bug when the discussion has settled on a specific approach.

So, actually, effective use of such a system comes down to:
I'm sure this set of common mistakes and guidelines is incomplete, but I think if you follow this advice, working with Bugzilla and other bug reporting systems will not only be more fun for everyone, but also will make fixes appear faster as developers can be more foused to specific working tasks.

Entry written by KaiRo and posted on March 10th, 2007 15:58 | Tags: Bugzilla, Mozilla | 1 comment | TrackBack

Comments

AuthorEntry

Smokey Ardisson

quote
How times change...
When I first started working in OSS bug trackers a couple of years ago, I read some instructions stating that a user should always make a comment when making a change to a bug or adding himself to the CC list. (It even may have been in documents on mozilla.org—though I can't find it now—especially given the number of old comments in old bmo bugs that do this.) It positively boggles my mind today that bug system instructions once advocated such an annoying and useless behavior :)

All the more reason we have to keep documents up-to-date, too....
2007-03-13 06:17

Add comment