the firefox-backlog flag

Gavin Sharp gavin at gavinsharp.com
Fri Apr 4 22:17:16 UTC 2014


Here's another way to represent what the backlog is.

Historically, our model for tracking bugs has been roughly:

a) Large set of old ignored/forgotten/UNCONFIRMED bugs
b) Much smaller set of bugs being actively worked on

How bugs get from the first set to the second is a relatively opaque
and somewhat arbitrary process - engineering leaders identified
priorities, engineers picked bugs, people scratched their own itches,
etc.

The backlog is intended to make the model more like:

a) Large set of old ignored/forgotten/UNCONFIRMED bugs
b) Much smaller but still relatively large set of bugs marked firefox-backlog+
c) Set of bugs marked firefox-backlog+ that are prioritized highly
d) Much smaller set of bugs being actively worked on

This is a more complete "funnel" for bugs, with clearly defined ways
for a bug to progress from one end to the other.

The process for bugs getting from a) to b) is the backlog triage
process I described earlier.
The process for bugs getting from b) to c) is the prioritization work
that Chad, Madhava and I go through that incorporates feedback from
the entire team and various stakeholders.
The process for bugs getting from c) to d) involves our weekly
planning meetings to select work for each iteration.

Gavin

On Fri, Apr 4, 2014 at 3:08 PM, Gavin Sharp <gavin at gavinsharp.com> wrote:
> Here's another way to represent what the backlog is.
>
> Historically, our model for tracking bugs has been roughly:
>
> (Large set of old ignored/forgotten/UNCONFIRMED bugs) -> (Much smaller
> set of bugs being actively worked on)
>
> How bugs get from the first set to the second is a relatively opaque
> and somewhat arbitrary process - engineering leaders identified
> priorities, engineers picked bugs, people scratched their own itches,
> etc.
>
> The backlog is intended to make the model more like:
>
> (Large set of old ignored/forgotten/UNCONFIRMED bugs)
> -> (Much smaller but still relatively large set of bugs marked
> firefox-backlog+) -> (Set of bugs marked firefox-backlog+ that are
> prioritized highly) -> (Much smaller set of bugs being actively worked
> on)
>
> This is a more complete "funnel" for bugs, with clearly defined ways
> for a bug to progress from the left to the right.
>
> Between
>
> Gavin
>
> On Fri, Apr 4, 2014 at 3:03 PM, Gavin Sharp <gavin at gavinsharp.com> wrote:
>> Given feedback from mconnor and others on my previous post about the
>> Firefox backlog
>> (https://mail.mozilla.org/pipermail/firefox-dev/2014-March/001502.html),
>> we're now tracking bugs in the backlog a little bit differently.
>>
>> We now have a "firefox-backlog" Bugzilla flag. It can be requested
>> from the wind (similar to how "tracking" flags can be requested), and
>> can be granted by members of a group called "firefox-backlog-drivers"
>> (more on that later).
>>
>> A quick recap about the goal of the backlog: the Firefox backlog is a
>> tool to help focus and organize the Firefox desktop team's efforts on
>> the bugs that matter most. Chad, Madhava and I prioritize the work in
>> that backlog, and our teams (UX, product managers, engineers) pick
>> work from the "top" of that list to complete during our 2-week
>> development cycles. The backlog is a public list of bugs the core
>> Firefox team considers most important, so it's also a great source of
>> bugs for other people looking to contribute to Firefox and have the
>> biggest impact.
>>
>> In an ideal world, the backlog would be roughly equivalent to "all of
>> the Firefox bugs in Bugzilla". Unfortunately, we don't live in that
>> world - there are far too many bugs in Bugzilla for us to prioritize,
>> and many of them are not actionable or useful. Historically the way
>> we've dealt with this problem has been to ignore large swathes of
>> bugs, and use ad-hoc methods for prioritizing work. The backlog triage
>> process is intended to give structure to those ad-hoc processes, and
>> make them more transparent and visible.
>>
>> I've written up a set of criteria for whether a bug should be listed
>> in the backlog:
>>
>> https://wiki.mozilla.org/Firefox/IterativeDevelopment#Backlog_Triage
>>
>> The very simple way of looking at it is this: the criteria for a bug
>> being in the Firefox backlog are roughly the same as the criteria for
>> a Firefox bug being confirmed (i.e. NEW, as opposed to UNCONFIRMED),
>> but with the addition of a judgement call about the cost/benefit of
>> the bug, and our likelihood of addressing it in the near future. That
>> judgement call is highly subjective, and so we need to reach consensus
>> as a team about how to make it.
>>
>> One way we plan to reach that consensus is to have regular backlog
>> triage meetings, as mentioned in my previous post. A few
>> representatives from various teams have already completed the first
>> few backlog triage meetings, and as we build a shared understanding of
>> what the backlog is, I expect to distribute that responsibility wider
>> and wider throughout the community, expanding the size of
>> "firefox-backlog-drivers" to eventually encompass most core
>> contributors.
>>
>> That's a lot to process, and is a significant change in how we track
>> work on Firefox, so please, ask any questions that come to mind and I
>> will try my best to clarify.
>>
>> Gavin



More information about the firefox-dev mailing list