Why we need to Radically Change Bugzilla, Part 2


First, let me clarify a few things. By “End-User Bugzilla” and “Developer Bugzilla” I didn’t mean two totally separate Bugzilla installs. While that could be made to work, there are much easier ways to go about it that are much better. I will continue to call it “End-User Bugzilla” for lack of a better term however. The End-user Bugzilla could take the form of a product on BMO, a separate database on another website, a whole range of ideas, I’ll lay those out in a future post.

Current Bugzilla

While slightly out of date, this chart does give the basic idea of how every bug in Bugzilla goes through life. Developer bugs miss the UNCO state usually, but all end-user bugs follow this pretty much from beginning to end. In theory. In reality, end-user bugs sit in one of two states for years. UNCO and NEW. Very few become ASSIGNED or FIXED. The majority end up becoming INVALID, DUPLICATE or INCOMPLETE. Reducing that number, and raising the number of FIXED bugs is the challenge here.

Proposed Bug Process

For Developers, the bug process remains largely the same, a bug is reported, assigned (or resolved WONTFIX, etc.), then FIXED. For End-Users, the bug is put into a staging area. This staging area is where triage, QA and Support can all work together to improve bug reporting for out end-users. A user reports an issue (ticket, bug, whatever we want to call it). Triage jumps on it, ensures that the issue has all the information it needs, filters out spam, and if it is ready, sends it off to the proper “department”. Support questions go to SUMO, Extension bugs are tied into AMO somehow (feedback on an extension perhaps?), and legitimate bugs are sent to BMO, where they are then put into the proper product and component (this is all a one-step process, much like changing products on BMO today). Issues where the reporter never gets back are marked INCO within a certain period of time.

Why this is Better

For Developers, the excess wading through bugs submitted by end-users that may or may not be real bugs is avoided. BMO is devoted to only real bugs, and triage doesn’t have to worry about tripping over a developer and visa versa.

For End-users, this ensure more personal attention. Instead of having their bug ignored, marked INVALID (how uncaring does INVALID sound? It is a valid issue to them, or they wouldn’t have raised it) or some other confusing resolution. Instead of simply being brushed off (which, no matter how we mean it, it appears that way to the general public), users will now get their bug moved straight into the proper place. If they need support, they are happy because boom, there it is. If they did find a bug, it can be an entry into more bug reporting in the future because we move it straight into BMO. If it is another issue like an extension, then the information can be moved where it needs to be. Perhaps even feedback can be taken, then submitted to Hendrix as higher quality information.

A Clearing House

So in essence I envision the “End-User Bugzilla” as a central place for input and feedback from users. Taking the loose ends and pieces of Mozilla’s carious portals, and tying them all into an easy place for end-users to get help, report issues, and make a difference.