As a lead developer with an Open Source project on SourceForge and a program manager at company that produces software commercially I have used private and public bug databases. Sometimes I've wondered what it would be like if the users of Microsoft products had access to our bug databases and could vote for bugs like in Bugzilla. There are two main things that decide if and when a bug will be fixed when bugs are being triaged at work. The first is the priority of the bug but how this is determined varies from component team to component team and is more a holistic process than anything. The second is how much work it would take to fix the bug and whether it takes up too much of the schedule ( a bug that takes a week to fix will less likely be fixed than 4 bugs that will take a day a piece). I've always thought it would be interesting if one of the factors we used to determine the priority of the bug included direct customer feedback such as the number of folks who'd voted for getting the bug fixed.

There are down sides to every proposal and I discovered this post from Matthew Thomas (who seems to have abandoned his blog) entitled discussions in unwanted places where he lists some of the problems with public bug databases that the Mozilla project has faced. It should be noted that the Mozilla project is probably the largest and most significant instance of a software project with a public bug database. Matthew writes

While none of these channels may be intended as an avenue for discussion, humans have frequently demonstrated that they will try to converse even in areas where discussions are not wanted.

The saddest example I know of is Bugzilla, a Web-based system originally developed to track bugs and requests for enhancement for the Mozilla software, and now used for a variety of other projects as well.

By default in Bugzilla, when someone adds a comment or makes any other change to a bug report, everyone associated with the bug report will receive an e-mail message: the reporter, the assigned programmer, the QA contact, and anyone else who has registered their interest. This can result in a lot of e-mail being sent.

It’s not so much of a problem when Bugzilla is used by a small or professional team, because participants have social or disciplinary incentives (or both) to ensure everything they do in the system is productive. But when Bugzilla is used by a large mostly-volunteer team, as it is with the Mozilla Project, you get problems. People argue about whether something is a bug or not. They argue about its severity. They argue about its schedule. They plead for the bug to be fixed soon. They throw tantrums. They make long tedious comments no-one can understand. In short, they treat Bugzilla as a discussion forum.

As a result, over the past few years several of Mozilla’s best programmers have begun to ignore most or all of the e-mail they receive from Bugzilla, for the good reason that they’d rather be fixing bugs than wading through Bugzilla discussions. The correct response from Bugzilla’s maintainers would have been to make Bugzilla harder to use as a discussion forum, but instead they made it easier. They added linkable numbers for comments, making it easier to reply to them in new comments. They made the comment field larger, aiding long and rambling comments. They added a mechanism for quoting a previous comment when replying, aiding long and rambling conversations. And they could have turned off the quoting feature in the installation, but they left it turned on.

Each of these decisions appeared to be good and proper, as it improved the usability of Bugzilla for those writing comments. But the purpose of Bugzilla is not to collect comments, it is to track bugs. And the resulting blizzard of comments has made Bugzilla less useful for tracking bugs.

It seems obvious that having a public bug database leads to information overload but what is surprising is that the problems don't come from too many spurious or duplicate bugs being entered [as I expected] but from people actually using the bug database how it is intended.

Well, looks like another idea I had turned out not to have been as good as I first thought.


Monday, March 29, 2004 8:59:09 AM (GMT Daylight Time, UTC+01:00)
I found a bug in Mozilla a year or more ago and reported it in Bugzilla. The bug was repeatable and easy to understand. Having never dealt with a system like this before, it was great to get an immediate reply direct from a developer.

I recently also reported an error on an MSDN page using the "comment on this page" facility. Here I also got immediate feedback from a real person at Microsoft (I almost fell off my chair!).

The great thing about these two experiences was the initial feedback that my comments had been understood and appreciated.

With Mozilla, since the initial bug report, I have received lots of Bugzilla emails which mostly say "did we fix this in build xxx?", "has it come back again?", "is it the same as bug yyy?". It still isn't fixed a year later so, although I'm glad I reported it, I'm not sure it did any good. I had thought an Open Source project would result in a faster fix, but it seems not.
Julian Gall
Wednesday, March 31, 2004 9:49:24 PM (GMT Daylight Time, UTC+01:00)
"a bug that takes a week to fix will less likely be fixed than 4 bugs that will take a day a piece..."

I hope there's more to it than that. What if the one bug causes data loss (considered an ultimate sin in programming) and the 4 bugs are UI related and could never cause data loss?

As for Bugzilla specifically, it's got some very nice features, and some completely terrible features as well. ;)
Sunday, April 4, 2004 6:44:21 AM (GMT Daylight Time, UTC+01:00)
Priorities solve that issue. Data loss/corruption and security tend to be higher on the priority list than anything else.
Arpan Desai
Comments are closed.