Why we Need to Radically Change Bugzilla and Triage, Part 4

I could also title this, What Needs to be Done to Ensure this Works.

I’ll try to summarize in a few short paragraphs.

Mozilla Needs Official Triagers

Instead of relying on a community to handle all the bug triage, Mozilla needs to hire several people to work full-time, who’s job it is to triage. I think that a Firefox/Toolkit, a Core, and a Thunderbird/Seamonkey triager are the minimum. By hiring triagers, Mozilla will help eliminate several problems.

  • The Mozilla triagers will be able to coordinate the community. Instead of relying on individual uncoordinated effort, the Mozilla triage team can focus the community on areas of BMO where their efforts would be most effective at the time.
  • Instead of each person having their own ways to handle different types of bugs (how long should a closeme bug wait before being closed), the Mozilla Triagers could lay out guidelines for all bugs in their product(s). they would be able to coordinate with developers on how they want specific bugs treated, and ensure the community followed the guidelines.
  • Mozilla Triagers would ensure there were always people to provide cover of UNCO bugs. By ensuring there are people who are paid to work on triage, the chances of having 13,000+ bugs would be far less.

The community is a very powerful tool if used effectively. But Mozilla has never learned how to harness the triage community. Bugdays have been of limited effectiveness. They are useful, but not coordinated enough to have long term impact. The QA team tried to assist with Triage, but they are divided between so many projects that devoting alot of time to triage is understandably difficult.

By centrally organizing and assisting triage, the Mozilla Triage team would improve our current triage process dramatically. And that is an understatement. Without Official Mozilla recognition and assistance of triagers, I see the community totally disappearing within two years.

And I know there will be various forms of “why do we need triage” in the comments. If you feel that way, please think about what Bugzilla would look like without the triage community right now. I plan on posting about this shortly, on why we need triage, and why it is so difficult.

Advertisements
  1. Well, full-paid Mozilla triagers would be great for fully-sponsored Mozilla projects like Firefox or (IIUC) Thunderbird. But what about Mozilla community projects, like (among others, I suppose) SeaMonkey? I don’t think that Mozilla employees could be expected to spend a significant part of their “paid” time to such projects (several of them already lend a hand occasionally, and the SeaMonkey community is thankful to them for that, but we know how ticklish some matters become as soon as they become noticeable on the profits-and-losses statement under a corporate balance sheet).

    • I would say anywhere is a start, and if we began for example with triagers for Firefox, Thunderbird, Core, and “other products”–that might be a better starting point. The latter-most would handle the smaller, more random projects including Seamonkey (we could even have their official duty be leading the group). If we had specialists for the big projects and then someone versatile who could–on assignment–lend a hand with Seamonkey one week and Firefox Input the next, Webdev or Webtools on another, and so on: I think that would work perfectly. If necessary, after two or three quarters of building such a team, amendments could be made to the group and its strategy.

    • Paul [sabret00the]
    • May 27th, 2011

    I’m a big fan of this idea. As someone who files bugs, I can say that it’s always nice to not feel ignored. Thus if a bug is quickly marked as either NEW or WONTFIX its always a nice feeling to know your contribution has been considered.

  2. Neither of your first two bulleted-problems requires a full-time triager. Or even a Mozilla employee, for that matter. In fact, I’d even go so far as to say that any plan that has employees dictating requirements to the community is fundamentally broken. But that’s a separate issue, and I don’t think that was really your intention. đŸ™‚

    Organizing the community can start today, by the community. Gather up the folks for are doing triage on a email list / newsgroup / forum / blog, and figure out a roadmap. I think you’re actually doing this yourself already!

    Triage guidelines don’t necessarily need formal rules. I’d suggest starting off with a set of defacto-guidelines tweaked to be consistent. Toss ’em up on a wiki page, then post about them on Planet and moz.dev.planning to see what wider feedback you can get from developers and QA. Some module owners might have thoughts too, depending on the area.

    • I agree with you that the community can definitely handle those two bullet points on their own. They have been trying to already. But without someone who is dedicating full-time work, and has authority to make changes and be an advocate for the community among Mozilla, it is going to be haphazard at best.

      And I’m not meaning the Mozilla traiger should dictate to the community, but instead be there to guide them, take new community members under his/her wing, help answer questions, lay out basica ground rules. But not micro-manage the community either.

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: