Why we need to Radically Change Bugzilla, Part 2.1

Just a quick post to clear up something that I’ve noticed in the comments. I am not proposing that BMO be any more locked down than it is. I don’t want to make it less open to the public, and I feel that keeping BMO open is what will help drive Mozilla forward. That is why I am proposing this change. So then end-users who have legitimate bugs can have them put right in BMO, while those who just need support and help can get it without feeling that they are being brushed off. By treating EVERY report as important, we can go far in helping increase the goodwill of end-users towards Mozilla.

Also, the Staging area will not be required. I envision it as something like the Guided bug reporting form. Enabled by default for new users, but can be turned on and off at will. If someone who has been using BMO for years wants to enable/disable it, that is totally possible. Bugs can also be moved in and out of the staging area. For instance:

  1. Issue is reported to staging area. At first glance it is a support issue, triage kicks it to SUMO.
  2. Sumo works with the reporter and determines there is an underlying bug in Firefox that is causing the issue. SUMO moves the bug back into Staging.
  3. Triage determines the proper product and component to move the issue into, and does so.
  4. Developers in BMO Fix the bug.

In that case the bug went from Staging to SUMO, from SUMO to staging, and then from STAGING to BMO. If the SUMO people knew what component the bug could go into, they could have moved it directly there as well, skipping step 3.

Advertisements
  1. I’m somewhat weary of adding yet another “reporting and feedback” channel for users, next to SUMO, input, crashreporter (OK, that one’s very specific) and BMO. Couldn’t we just direct end users more strongly to SUMO and input?

    • I’m not envisioning this as another channel, more of a step towards the ones we already have. Perhaps a product in BMO “Needs Triaging”.

  2. What’s the difference between the “staging area” and the UNCONFIRMED state?

    Gerv

    • Gerv: There were some comments about that on the previous post.

      Tyler can of course answer for himself, but as far as I understand it, the main difference is that the rules and parameters around using the UNCO state are decided (and acted on) by developers (which causes inconsistency between modules and conflict between developers and triagers), whereas the “staging area” would be largely unseen by developers, and managed according to rules decided by triagers.

      • I would say that is a fairly accurate description. BMO right now is not friendly towards end-users, nor towards traigers. The Staging area would be a place specifically designed for them to do their work, and BMO would be for developers to do theirs.

  3. Tyler Downer :
    I would say that is a fairly accurate description. BMO right now is not friendly towards end-users, nor towards traigers. The Staging area would be a place specifically designed for them to do their work, and BMO would be for developers to do theirs.

    If BMO is not friendly towards triagers, we need to fix BMO. Lots of triage would still go on there even if we had a ‘staging area’, and if that’s miserable for people, that’s a problem.

    I agree that making BMO more friendly towards users is not a good plan – because for 99.99% of users, BMO is not where they need to be, and making it more non-geek-friendly will almost certainly mean making it less useful for developers. (Unless you have a way to square that circle.) But my suggested fix for this is to divert people off to SUMO or Input before they even file a bug, rather than have them file bugs which then need to be moved around.

    Gerv

      • Michael
      • May 25th, 2011

      “If BMO is not friendly towards triagers, we need to fix BMO”

      The question is whether that is actually possible at this point.

      To make it work, I think there would need to be some rules that apply to everyone (including all developers) and some rules that apply across all modules. Various developers and modules use bugzilla in their own quirky ways such that whatever standardisation is done, someone is going to have their previous methods and workflow broken, which is going to take away time from “real” work, in order to fix triaging problems which may not exist in their area of work.

      If you can get all the developers to sign up to that, then great. I know you personally have attempted various changes in the past, but I think generally some people/modules have opted-out of whatever change you were making, or just carried on as before by ignoring whatever it was you wanted to do…

      • I think that the only way to make “rules” would be to designate someone as the ultimate authority in triage matters, or a team of people, and force every developer to follow them. But I doubt this would be accepted.

  1. August 27th, 2011
  2. September 7th, 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 )

Twitter picture

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

Facebook photo

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

Google+ photo

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

Connecting to %s

%d bloggers like this: