The Mozilla Bug Firehose - Design Decisions
There could be many blog posts about the Mozilla bug firehose. This is just about dealing with one particular aspect.
When a bug comes into Mozilla it needs to get triaged - someone needs to figure out what to do with it. Triaging is an effort to try and get bugs appropriately classified to see how critical the bug is. Part of shipping a product every 6 weeks is that we have to try and fix crucial bugs in each release. To do that you have to read the bugs reports and try to understand what’s happening.
We set aside a certain amount of time for triage meetings every week to triage those bugs. With product, engineering management, QA management and a bunch of engineers, those meetings are expensive to the whole organisation. So we started getting pretty ruthless on those triage meetings to keep them as short as possible .
One category of bugs that we got a lot of (an awful lot of) in WebExtension is a “feature request”. This is where someone is asking for feature that we currently don’t provide in the WebExtensions API. This one bug could slow down a whole triage as all the people look at a bug and think about it and try to decide if its a good idea or not. That’s a terribly expensive and inefficient way to spend the triage meeting.
Instead we decided that we can do a few things:
- We can usually determine quickly if a bug is within the bounds of WebExtensions or not. If not, it gets closed quickly.
- We can usually determine quickly if a bug is reasonable or not. If it is, it goes into the backlog.
- The rest go into a seperate bucket called design-decision-needed.
Then we have a seperate design-decision-needed meeting. For that meeting we do a few things:
- Pick a few bugs from the bucket. For arbitrary reasons we pick the 3 oldest and 3 newest.
- Try to involve the community, so we let the community know about the meeting and bugs before hand. All our meetings are public, but we specifically feel community should be involved in this one.
- Ping the reporter before the meeting asking if they want to come to the meeting or enter more details in the bug.
- Try to spend 5 minutes on each bug.
- Try to find someone to argue for the bug, especially when everyone thinks it shouldn’t happen.
There are currently <a href=”https://mzl.la/2BhdVZP>107 bugs needing a decision</a>, 57 have been denied, 133 have been approved and 2 deferred. The deferred bugs are ones where we still have no real idea what to do with.
We are hoping this process means that:
- Contributors can feel comfortable that before they start working on a bug, they know the patch will be accepted.
- Everyone’s time is respected, from developers to the reporters.
- The process constrains internal developers time to prevent them from being overwhelmed by external requests.
The single best part of this process, was that we got our awesome Community Manager - Caitlin to run these triages. She does a much better job of working with the contributors and making them welcome than I can do.
So far we feel this process has been pretty good. One thing we need to improve is following up with comments on the bug quickly after the meeting. Some have fallen through the cracks and we struggle to remember later on what we discussed. Ideally, we do need more contributors to work on the bugs that have been marked as design-decision-approved. They are all there for the taking!