Why we Need to Radically Change Bugzilla, Part 3

Well, this is the meat of my series, where I stop talking about hypothetical solutions, and start to think about some real, achievable fixes. The main thing I will focus this post on is the “Staging Area”, and the most practical way to handle it. I may not cover all the bases, so please, in the comments, point out edge-cases I have missed and I’ll do my best to address them.

A New BMO Product

So far, of all the possible ways to create a staging area I have thought of, a new BMO product seems the easiest, most cost-effective, and relatively easy to implement. While there are both pros and cons, I think that we can create a very effective staging area with a new BMO product.

The Vision

A Product called “Un-triaged Bugs”.
Components inside the product for every individual product that needs triaging (Firefox, Thunderbird, Seamonkey, Etc.)

A reporter without CANCONFIRM privs files a bug. They either go to BMO, or to the Staging Area Front-End (issues.mozilla.org for example, different UI, ties into the same backend). Using a redesigned Guided Bug entry form, they file their issue. Along the way they are asked if their issue has already been filed, or encouraged to go to SUMO. If they decide to file an issue, then it is automatically sent to the Un-Triaged Bugs Product.

In this product, all Bugs are reported as UNCO, all bugs are very much simplified. The Reporter is only exposed to fields they need to see. Blocking flags are gone, CC list is gone. Whiteboard, milestone, priority, product, component, importance, blocks and depends on are all hidden from the user. Users with CANCONFIRM can see the fields, users with EDITBUGS can edit all the fields. But to the first time bug reporter, a much simpler, easier to read, and friendlier bug page is used. All those fields are not likely to be needed by a first-time bug reporter, and only serve to confuse them (of course, this can be turned on and off in the preferences).

Then, Triage jumps on the bug. They know that nearly all bugs sent to the staging area are end-user bugs, so this makes their life much easier. Bugs that are actually support questions are sent to SUMO. Bugs that need to be directed to an extension developer are sent to AMO in a similar way. Feedback is sent to Hendrix. After sorting through the bugs, then Triage digs into the “try with a fresh profile” “try with a recent Firefox version” “update flash” “give a stacktrace/testcase” questions.

Once enough information has been gathered, then the bug is morphed into the proper product and component. Example, Bug XXXXXX is filed against Firefox, and concerns the location bar. After triage gathers information, they move the bug to Firefox:Location Bar. At this point, the bug is marked as NEW, and developers can jump on it and begin work. The developers can make decisions such as WONTFIX, WFM, INVALID, or fix the bug.


  • Unconfirmed bugs and bugs that are not bugs are totally separated from the bugs that are really valid. This eases the tension on BMO between devs and end-users
  • Eased workload on triage. Instead of having to separate developer bugs from end-user bugs, Triagers know all bugs in the Un-Triaged product need attention, while those in specific products have already been triaged and are ready for a dev.
  • End-users no longer have to try to figure out products or components. They select the product on the guided bug entry, and triage takes care of the rest.
  • BMO is no longer balancing end-user bug reporting and development in the same place. It is separated out without too much additional work


  • Even with improvements, Bugzilla is still just not very pretty for end-users. Perhaps this post can help that somewhat.
  • This will require significant changes in how triagers work, instead of being spread out, everything is dumped into one place. This will require changes and more efficiency or this pile will get out of control.

In my next post I plan on discussing what needs to be done to make this work more in detail, as well as specifics of how this component would work.

  1. Again, this is a step backward.
    – Even a user without CANCONFIRM will on occasion encounter crashes, and if the “Importance” drop-down weren’t hidden he’d rather soon find out that crashes belong in the “critical” severity and deserve the “crash” keyword.
    – Even a user without CANCONFIRM will on occasion be asked “file a bug about your problem, and CC me on it”.
    – This actually raises the barrier against learning where what kinds of bugs actually belong: instead of having the possibility to choose, let’s say, Firefox::Bookmarks&History or Firefox::Preferences, they’ll always be dumped into Untriaged::General, and it will be the triagers’ job to do even what little triageing is now done by unconfirmed reporters.

    • I am not sure how much triage you think end-users do on their own bugs. I can tell you it is very little, and that is due to the complexity of BMO. More often than not I am moving bugs back and clearing keywords that aren’t properly set, priority, milestone, RESOLVED FIXED when it never was. So I think we need to strike a balance between hiding some features for new-users, and educating them. I should note, all of these features can be turned on and off in preferences.

    • Mark
    • May 26th, 2011

    First: So far, so good. This looks like a good direction to go.

    Second: I’m guessing that “Un-triaged Bugs” isn’t intended to be a user-facing product name. (half of users won’t fully understand what a bug is and the other half what ‘triaged’ means)

    • Josh T.
    • May 26th, 2011

    Bugzilla is what got me interested in Mozilla. Once I got past its complicated-ness (which took about a year), I became really interested in the foundation’s work.

    While I love this idea, I’m worried that this might prevent people from going the same route as me, by using bugzilla to see what’s going on “behind the scenes” so that they can gain an interest in the development of the projects, which will hopefully encourage them to volunteer for development.

    If this goes ahead, I think that the “second bugzilla” should have a button to take users to see the “developer bugzilla” version of their bug.

    • Ed
    • May 26th, 2011

    Whatever other solution/changes are made, I think a critical piece of the puzzle is to reduce the amount of time it takes to triage bugs, since manpower is ultimately the end problem here.

    Whenever I’ve helped with triage, 90% of the time/effort is taken up with things like:
    – “please can you try with a new profile/safe mode/…”
    – “for crashes please provide a stacktrace/the ID from about:crashes”
    – “please try with a newer version, the version you are using is too old”
    – setting the version field manually since the UI doesn’t do it for them
    – setting a bug to WFM since the reporter said it now works, but didn’t know to change the state of the bug
    …and so on.

    The new guided bug entry form in bug 657317 will fix some of these, but I think some further improvements can still be made.

    There should really be no reason why a human has to manually make these common template replies – the fact that they do, just means the bug submission process doesn’t give the user enough information upfront / in a form they can assimilate.

    Things like:
    – Specific instructions *before they submit the bug report*, for how to test with a new profile vs safe mode or how to download the latest nightly and test with that.
    – Telling them how to get a stacktrace upfront, if the word crash is detected in the bug title
    – Better feedback for the end user as to what to do if they later find out their problem is solved. (If end-uses are encouraged to be more proactive about closing their bugs themselves, then the triagers will have more time for everything else).

  2. This “staging area” is just the “General” component with a new name. This IMHO wouldn’t go nowhere useful.
    What we need to do, IMHO, is to be more aggressive to get users to not even file their report in Bugzilla, but put it into input or SUMO instead.

    • No it is not. There are valid bugs the need to be sent to firefox general. The purpose of the staging area is to seperate the valid new bugs from the UNCO bugs, making life much easier for triagers.

  1. August 27th, 2011
  2. September 7th, 2011
  3. December 23rd, 2011

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: