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 Phraswewise.com 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 mozilla.org 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.
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.
requests for enhancement
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 mozilla.org 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.