Managing build team expectations: the bug queue
Posted 3 years, 1 month ago at 15:33. 1 comment
The Mozilla IT team sets the gold standard for managing their bug queue down to near-zero on a daily basis. It’s an admirable accomplishment, and one that the build team would like to replicate.
Ironically, this may actually have the side-effect of making people less happy with us in the short-term.
The build team continues to be pretty busy. That’s not exactly news, but our current bug list belies what we’re actually working on. None of us are actively working on all of the 10 or so bugs that are currently assigned to each of us. It’s part historical artifact and part poor queue management.
One of the ways that IT manages their queue so effectively is by being absolutely ruthless about re-assigning and closing bugs. Bugs don’t stay unassigned, if IT is blocked on someone else outside the team the bug is immediately re-assigned, and bugs waiting on input are closed or WONTFIXed fast if there’s no response.
Our first goal as a team is going to be triage. We’ll start by re-assigning bugs already assigned to individual team members back into the general pool where appropriate. I’m going to do this to my own build bug queue today. This will give everyone a more accurate picture of what is actually in progress.
After that, we’ll get together as a team and triage down the build bug pool. The exact criteria we’ll be using for triage is still under discussion. Where appropriate, we’ll comment in bugs on priorities and time frames, but in many cases, we’ll be swinging a big WONTFIX stick. The end goal is to get the build team to a state where it has never (to my knowledge) been before: able to respond quickly to new requests without distraction.
We’ll get Justin to hold our hands if we get scared.
When *your* bug ends up back in the general pool over the next few weeks, please don’t take it as a slight. However, be prepared to fight for your bug if you think it’s important.
