the firefox-backlog flag

Gavin Sharp gavin at
Fri Apr 4 22:03:43 UTC 2014

Given feedback from mconnor and others on my previous post about the
Firefox backlog
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:

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

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.


More information about the firefox-dev mailing list