As some of you may know we have over 900,000 thousand bug reports in bugzilla.mozilla.org these days. Around 120K of those are open bugs.
I keep an eye on the incoming bugs, which are still around 350-550 for any 24 hour period and peck away at those. Many people in QA and various engineering teams also keep watch over the incoming bugs so that problems are caught quickly, escalated appropriately, and stuff gets fixed and released as soon as possible.
But the incoming are just one thing among many. Lately I’ve been working on a fairly arbitrary goal. That is to bring down a specific number, the bugs filed for Firefox that are in the “Untriaged” component, where the last comment was by the person who reported the bug. I have it on my todo list as “FFUntriaged”, so I think of it that way. FFUN!
When I started putting half an hour to an hour a day into this, the count was well over 500 bugs. Now it is closer to 400. I answer some from the front of the queue and some from the tail end, which right now goes back to February 2012. The older, 2012 bugs are mostly obsolete at this point, but I have caught a few that are still valid, and that are now categorized in a product and component that brought them to the notice of the developers who may already be working on similar issues.
Of the bugs that I end up closing, a bunch of them probably should have been support questions in the first place. I resolve them INVALID if they are reallky support questions because they aren’t and weren’t bugs in Firefox. If I can’t tell what was going on, and the reporter doesn’t answer my “needinfo” query, I can resolve the bug INCOMPLETE since there was never enough information to tell if it was really a bug or not.
A few of these long-untriaged Firefox bugs ended up in the RESOLVED WORKSFORME status, which I think of as: when the bug was reported, no one was able to reproduce it, I can’t reproduce it now, and maybe also the original reporter can’t reproduce it. Maybe it got fixed along the way. It doesn’t seem important enough to anyone to pin down exactly what fixed it. It just works now. Resolving it seems ok to me, since that doesn’t erase any history: the bug report is still findable if it comes up again.
The FFUNtriaged bugs project has been fairly satisfying just to watch the number come down over time. Pretty soon we will have it down to something reasonable, like under 30, and actually recent bugs instead of cruft from a year ago. Then I’ll pick a new little project!
And now a digression about duplicate bugs.
A few bugs from FFUNtriaged end up being marked as duplicates. I catch a few, but more often someone more experienced notices the duplicates after I do something else with them, which sends bugmail or puts a report into a new product or component. Some reports just sound like they must have been reported before. DUPing them is a good way to establish connections and direct the original bug reporter to where the action or discussion is. There is good advice in Screening duplicate bugs article on MDN.
There is not only a
In theory the better we get (collectively) at duping bugs, the more useful the lists of most-duped bugs will be. It may be a self perpetuating cycle though, to where we learn the most-duped ones, then dup more bugs to them. I have thought before it might be fruitful to hunt after (or ask someone for a lead to) closely related bugs and sort through them to see if any are obvious dupes.
Things I know about automatically as dupes are: anything involving shortcut keys. Layout complains about tables and images. Anything to do with bookmarks. All those are worth a search and a quick scan of a list of bugs with similar words in the summary and then a bit of digging!
Sometimes people are a bit upset that “their” report gets
duped to an already existing bug. I don’t have enough experience (after 8 months triaging) to really have a sense in the patterns of what gets fixed and why. But when a bug is duped to an older one, the people who get bugmail on that older bug are going to get a poke of some kind, so at least that brings the issue to possible attention. And over time, it may affect how teams or engineers set priorities or figure out what to fix or escalate. So I think it it likely useful.