Firefox Bug Triages

11 March, 2013 § 9 Comments

Smash!!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.

Tagged: , ,

§ 9 Responses to Firefox Bug Triages

  • Landpaddle says:

    I am enthused to see that this course of action has been panning out for you guys!

    No, really, resolving bugs and squashing them is not only good for internal documentation; practicing thorough resolution also gives the user an image of well-organized coders and forward technical movement when browsing the bugzilla repository.

    A good move in every sense of the word. And hey, maybe you’ll stumble across a few genuine bugs along the way. I doubt that fuzzing has already picked up all there is to fix.

    Good luck out there!

  • ferongr says:

    The c2p/flashblock comparison is wrong . Flashblock is many grades below the built-in c2p functionality. It won’t show a hint to enable hidden plugin elements (e.g. the Soundcloud mp3 player), it breaks plugin functionality more often and it conflicts with other extensions.

    But then, it’s not really a problem with Flashblock but rather the really excellent work done by Mozilla developers with c2p.

    • msujaws says:

      Thanks, I’m glad to hear you like the native c2p implementation. My point was that FlashBlock, Adblock Plus, and other add-ons can offer features that we would be unwilling to take in Firefox, such as ABP’s disabling of social widgets.

  • I’ve really enjoyed your bug days and think you have a very effective triaging format! As a newcomer to Mozilla I also felt reassured that my triaging mistakes would be caught and fixed — the way you set up the etherpad means that anything I wasn’t sure of could be put on an obvious list for someone else to take more time to re-check.

  • J says:

    If you intent to fix old bugs, please have a look at bug 116083.

    Bugs shouldn’t live > 11 years.

    • msujaws says:

      It’s OK for bugs to exist for > 11 years. There is no definitive time limit that a bug must be fixed or closed within.

      That particular bug appears to be hard and not on anybody’s radar, however it looks like we would take a patch for it if somebody came along and wanted to fix it.

  • fbender says:

    Will you also check the unconfirmed bugs? Might be worthwhile to do so before tackling the post-2018 work. I also suspect this work is finished rather quickly, as many UNCO bugs may be obsolete (BTW, how about a new RESO status OBSOLETE which indicates that bugs no longer apply?).

    • msujaws says:

      I don’t think we’ll use this process to check unconfirmed bugs. The signal to noise ratio of unconfirmed bugs is much higher than bugs marked as NEW. There is probably a better way to tackle unconfirmed bugs, but I haven’t thought deeply about them yet. Most components have people actively watching the bug traffic, and will confirm bugs that they deem legitimate pretty quickly.

      As for an obsolete resolution status, I think our current statuses work well enough. I agree that having an “obsolete” status would be pretty straightforward, but there would then be a large number of previously-closed bugs that would be using the wrong status.

      Basically, bugs can be fixed through multiple means. A bug can be fixed by someone tweaking the code to no longer hit that particular case, or the bug can be fixed by someone replacing an entire feature with a new one. In each scenario the bug gets fixed, yet only the second one “obsoletes” it, so the difference between the two is pretty trivial.

    • fbender says:

      Yeah sorry, I forgot to add my second idea: Auto-close all pre-2008 UNCO bugs with status OBSOLETE (or is OUTDATED better? or sth else?). The benefit of this is of course to lower the number of open (UNCO) bugs, plus any reporter is reminded of his old bugs and can take actions to revive it (if necessary). However, this auto-closing should be done in steps of e. g. 100 bugs per day to not let some contributors get bombarded by emails.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

What’s this?

You are currently reading Firefox Bug Triages at JAWS.

meta