Yesterday I asked my first question at beta.stackoverflow.com, the new developer community put together by Jeff Atwood and Joel Spolsky. The question was: how do you enforce or maintain the quality of the bug reports in your bug tracker.

A common problem is low quality bug reports, perhaps one-liners, PEBKACs, or bugs that don’t contain enough information to reproduce. I’ve seen emails from developers go out complaining about this and how difficult it is to navigate around in the bug tracker because of this, and it seems it’s a common problem.

The root cause might be a lack of understanding of the development process by the bug reporters, or perhaps just laziness, but all bug trackers seem to eventually contain a large degree of low-quality bugs.

At one project I worked on, which to be honest wasn’t huge, we grew tired of all the weird bugs in our tracker, and had what we called a bug deathmatch - we bought lots of candy, booked a meeting room for an hour and a half (which is the time limit for productive meetings), gathered the entire team (which in this case was 4 developers and one QA engineer) and went through as many bugs as we could, either marking them invalid or assigning them to a developer. After we did this over three Fridays, we were done with all of the bugs.

I was a little skeptical at first, but it actually went really well, and we got rid of all of the low quality bugs. If you’re going to try to duplicate this though, you’ll need a quick thinking person to hold the meeting and make decisions. The problem is that if you spend too much time discussing a bug report, the team will grow tired, and you’ll spend too much time on this. The concept is to efficiently judge bugs based on the information in the bug report and the collective intelligence of the team. It’s important to keep the pace up when going through the bugs, if necessary marking them to be analyzed further by a developer, just to get it out of the way and move on to the next bug.

It worked really well, but I’ve only tried this once, and my feeling is that it depends a lot of the team.

As for the question on stackoverflow - someone has yet to answer anything groundbreaking, but I’ll let you know.