This is what the “Bugzilla Data Mining” entries have been leading up to. We’ve decided to attempt to use a semi-automated procedure to resolve some of the older untriaged UNCONFIRMED bugs. Here’s the plan – please let us know what you think.
- Once a date is chosen, we raise awareness of the following procedure using blogs, newsgroups and websites. We don’t want anyone to get surprised.
- At the appointed time, we turn off Bugzilla access to all except the person doing the change. This is to prevent things changing under us.
- We search for all bugs in the Browser, Firefox, MailNews, and Thunderbird products in state UNCONFIRMED where Last Changed Date is more than two months before the present.
(The data mining used “bugs not confirmed after two months” – this is a subset of that. We are using “bugs not confirmed, and untouched in the last two months”, because then we won’t accidentally catch ones which are being worked on, but taking a long time to get confirmed.)
- We then Change Multiple Bugs, and add the following comment:
This is an automated message.
This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after two months are highly unlikely to ever actually be fixed.
If you can still reproduce this problem in the latest version of the product (available from http://www.mozilla.org/products/) or, for feature requests, if you still believe we should implement this feature, please visit the URL of this bug (given in this mail) and add a comment to that effect, giving more reproduction information if you have it.
If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter.
- Two weeks later, we make a buglist of all bugs in the original list which have not changed since the date we added the above comment.
- Do Change Multiple Bugs, add a “robo-resolved” keyword, and resolve them as WORKSFORME with the following comment:
“This bug has been automatically resolved after a certain period of inactivity (see above comment). Anyone who thinks this is incorrect should feel free to reopen it.”
So that’s our best shot. Any such process will never be perfect – but, in a perfect world, we’d have the manpower to triage all the UNCONFIRMEDs properly. But we don’t. So, we are looking for something which keeps as high a percentage of the good ones, and throws away as high a percentage of the bad ones as possible.
Here’s the logic. Bugs which haven’t been confirmed after two months are very unlikely to end up as FIXED – either they get fixed via another bug, or get fixed ‘accidentally’, or the code gets rewritten, or something else. We could just throw the lot away and not lose too much. But we want to do better, so we try and find the ones which might, by getting the reporters to reconfirm them. Getting reporters to reconfirm bugs is good because it tells us that they still see it and, just as importantly, they are still interested in helping us fix it.
Once this procedure is completed, we would use BugDays and other mechanisms to attack the bugs which had received comments, with the aim of resolving them or confirming them, starting with the oldest. This way, we hope to make a significant dent in the UNCO pile, and turn up the needles in our giant haystack.
 If you are the module owner of another product, and want to opt-in, shout.
 People who are not interested in reading these mails can create a filter and use Run Filters On Folder in Mozilla or Thunderbird, targetting the phrase “This is an automated message”.
 We either resolve as WORKSFORME, or OUTOFDATE if we can get that resolution added to Bugzilla. This depends on whether anyone has time to make the modification.