Kiss the Future goodbye

Posted 5 months, 2 weeks ago at 19:49. 1 comment

Let it never be said that we don’t listen.

In response to the comments on my previous entry about Tackling the Release Engineering:Future queue and a number of conversations I’ve had out-of-band over the past few months, the release engineering team has decided to do away with the Future component. We will be merging all of the bugs therein back into the regular Release Engineering component.

Aside from the simplicity inherent in having fewer components to worry about, there were three main reasons we chose to do this:

1. No other group in the company/community has an explicit “Future” component where they can hibernate bugs.
2. People outside the RelEng team find the Future component opaque, and despite reassurances to the contrary, they often just assume bugs in the Future component won’t be fixed.
3. Moving bugs between the regular Release Engineering component and the Future component makes it very hard to extract meaningful statistics about how our bugs change over time (new bug rate, fix rate, etc.). This makes it hard to change our processes based on data.

What does this mean for you? Nothing, hopefully. I’m planning to move all the bugs out of the Future component on the morning (EST) of Monday, February 15th. People in North America will be on holiday, so this should be a relatively low-traffic time to make this change. My apologies in advance for the RelEng mail bomb you’ll be getting on Tuesday morning. :/

We will still continue to triage bugs using our three bucket approach, only the location of the third bucket will have changed. Our three buckets of bugs correspond to the following:

1. Untriaged: – state: NEW, assigned to: nobody, priority: none (–)
2. Triaged, assigned – state: NEW (we’re not working on it yet) or ASSIGNED (we’re working on it), assigned to: a specific release engineer, priority: P1-3
3. Triaged, unassigned (was Future) – state: NEW, assigned to: nobody, priority: P3-5

In the interest of further simplification, the RelEng team will eschew the Severity field as we move forward, although we won’t change any information already contained in that field if it exists. Instead, we’ll start using the Priority field more diligently. All bugs that have been triaged will have a Priority associated with them from here on out.

For reference, the various Priority levels mean the following to us:

P1: blocker, all other work on hold until this is fixed
P2: being actively worked on
P3: acknowledged as an issue, but not being actively worked on
P4: (future) goals that are either blocked on other work, or that simply have not been started yet
P5: enhancement

There was some concern within the RelEng team that developers might assume that bugs moved out of the Future component were now being worked on. I have faith that people will correctly interpret the implications of their bug still being assigned to nobody@mozilla.org as an indication that, no, their bug is still on the shelf.

Please note that this does not change the triage work that still needs to happen on these once-and-Future bugs, as described in the previous post. We’ve already made some good headway on triage this week, though. The number of “Future” bugs is now down to 304 from a high of 343. Kudos to the people who made that happen. Let’s keep up that great work.

Current Tunes: New Order - Blue Monday | Filed under Build/Release, Mozilla |