An experiment in Firefox bug triage

If you’ve been around Mozilla for a while, you probably know that Bugzilla’s “Firefox :: General” component has a bad reputation; a place where bugs languish and die without attention. It’s not entirely true — over the last year we’ve fixed 220 bugs there, closed 7500, and triaged and commented on many as well. But it’s true enough.

Part of the problem (and there are oh so many parts!) is that Firefox::General serves two very different purposes. One is as the default bucket for bugs from new users, or for when someone’s not sure where to file a bug. This is a real firehose. I don’t know how to get exact numbers from Bugzilla, but it’s easily thousands of bugmails per month (including the initial report, and following discussion to determine the problem and proper component). The second purpose is as a catch-all component for code without its own dedicated bugzilla components. The volume of bugs around this purpose is far more sedate, though it’s again hard to get numbers. It’s like trying to find a leak in a firehose by peeking into it. 🙂

So it’s time for a simple experiment.

We’re creating a new Firefox::Untriaged component (see bug 713163), which will serve as the new “inbox” for bugs from new or unsure users. Firefox::General will remain, and focus on being a good home for bugs without a more suitable component. (There is currently no plan to move the existing backlog of 6000+ open Firefox::General bugs over to Firefox::Untriaged. Maybe we should?)

The idea is that bugs filed into Firefox::Untriaged should end up moving elsewhere (or be closed, if appropriate), lingering only long enough for gathering enough info to move/close it. Firefox::General then becomes manageable as place for real bugs, just as any other component should be.

There are still many problems with our inability to effectively triage all incoming bugs (as fine contributors like Tyler Downer have often blogged about), and this won’t solve that. But it is a small step towards better stewardship of one piece of the problem.

3 thoughts on “An experiment in Firefox bug triage”

  1. Sweet! We’ll need to file bugs for a firefox-only product picker UI (with “Desktop” and the picture of a computer with Firefox and “Mobile” with the picture of a phone running Firefox).

  2. Just for a quick comment Justin, that many of those 7500 “closed” bugs were closed as INCO (~3800 by my count). INCO isn’t really a “resolution”, it is more “This may be a valid bug, but we don’t know, don’t have enough information, don’t care, don’t have the time to test, etc.” About another ~1500 were closed as Duplicate (which is a much better resolution than INCO BTW). And <a href="; 277 were closed as FIXED (my dates may be different than yours.

    What I’m trying to say is While yes, work is being done in General, the vast majority is simple cleaning up of old and forgotten bugs. With roughly 3% of the total bugs resolved in the past year being “FIXED”, while 45% were closed as “Forgotten (INCO)” that is a pretty sad ratio in my opinion. I would love for INCO to totally go away in fact, unfortunately it probably never will.

    Also, I would suggest moving all current UNCO bugs in Firefox General that have no comments to the Untriaged component. As we have no way of seeing which bugs have been triaged already, that is the best compromise that I can see.

  3. There’s nothing wrong with INCO as a resolution. If someone creates a bug saying “My Firefox doesn’t work”, and then refuses to provide more information, you resolve it INCO and move on. What else can you do? There’s no need to feel guilty about doing so, and any work retriaging that bug is wasted.

Comments are closed.