Firefox Bug Triages

Since our Firefox work week in Toronto, a handful of people working on Firefox have begun triaging some of our older bugs.

The goal of the triage is to look at old bugs (6 years and older) and either:

1. Resolve as fixed (fixed through some other means), wontfix, or invalid
2. Move to a different component, or
3. Leave as-is

Our first three triages focused on the following components:

• Firefox::Tabbed Browser
• Firefox::General
• Firefox::{Menus, Microsummaries, Migration, Page Info Window}

In the first three triage meetings we closed 257 bugs! We have only been focusing on bugs marked as “NEW”, meaning that they have been confirmed but work has not begun to fix them. The Firefox product in Bugzilla currently has 8,579 “new” open bugs, so these three triages have trimmed close to 3% off of our previous total.

How do we run the triages?

Before the triages, I run some Bugzilla queries to gather a list of about 175 bugs within Firefox components. I chose that number of bugs so each person can get about 25 bugs apiece (we tend to have about 7 people triaging).

The bug list is then split in to ranges of about 25 bugs in size and people assign themselves to one of the ranges using our etherpad. I then send out a meeting invite with a link to the etherpad and ask that people triage their assigned bug range individually before our meeting.

About a week later we have our triage meeting, where we discuss bugs that we were unsure of.

Bugs that need retesting are marked as-so on the etherpad. We hope to have a Firefox front-end testday sometime soon to go over the bug list that we have curated.

Where do we go from here?

A lot of these dead bugs were easy to close, but as we’ve cleaned them up the newer bugs (2008 and onward) are getting harder to close. They are more relevant and still exist as valid issues with the product. We are able to associate some of them with newer features that will fix them indirectly, and others we are able to turn in to “good first bugs” or fix outright (see my recent post for one example).

We are continuing to have more bug triages (we had another one today, which has so-far closed 24 bugs). After we have hit all of the Firefox components we should have less dead bugs in the system, and it will be easy to have triages that occur less often but cover the whole Firefox product.

We can also start triaging some of the more recent bugs and being more proactive about closing out bugs that don’t align with our goals.

We also need to schedule that testday that I mentioned above. I (or someone else) will have to coordinate with the QA team to schedule a day where people can help us test and close out some of these bugs.

What have I learned so far?

I’ve had a few takeaways from this process:

1. We should be more open to closing bugs when we know that there is not a realistic chance of the bug getting fixed. This line of communication is important to provide to the people that file bugs, and it also provides a permanent background as to our stance at the time. This is much more helpful when revisiting a bug than finding years of silence and inactivity.
2. Lots of feature requests carry great inspirations for add-ons. As we strive to keep Firefox lean and agile, we need to make sure that features that find their way in to Firefox are useful to over 95% of our users. Implementing an add-on allows greater potential and a deeper feature set than we would be able to pursue if the feature was standard to Firefox. One great example would be to compare Firefox’ click-to-play implementation with that of FlashBlock.
3. Splitting tasks like this up ahead of time allows our meeting to be very focused and fast-moving. I’ve participated in triages before where everybody at the meeting went through a list of bugs and discussed each one individually. While that allows for deep discussion on each bug, it’s not a very effective use of our time. Many bugs are easy to close, and ones that may require a deeper dive can be tabled until our meeting.