We’ve made some good progress since discussions around bug triage started last December.  At the time there were approximately 13,500 open Fedora bugs.  Today the count is 3,000 less at approximately 10,500.

While we talk about closing bugs a lot, ultimately the goal of Bug Triage is not just to close bugs.  The goal and vision for Fedora bug triage is to bring more sanity to the number of open bugs by helping to sort through bugs that cannot or will not be addressed while also establishing better expectations with our users about Fedora’s maintenance policy.  For those not aware, Fedora’s maintenance policy is two release cycles plus 30 days.  For example, Fedora 7 will go end-of-life (EOL) on June 13, 2008, two releases and 30 days after the GA of Fedora 9 which happened on May 13, 2008.

The graph on the right does seem to indicate that bug triage efforts are having an affect since they started.  An up to the minute matrix showing the breakdown of these bugs is here all open bugs is here.

It is also our hope that the bug triage team can help Fedora as project identify areas which need more attention.  Some initial anger and frustration was directed at the “triage bot” for touching so many bugs and closing many others (for unmaintained releases) that had been filed but never responded to by anyone.  This points to a potentially deeper problem that maybe in spite of Fedora’s desire to grow its package repository it is also not staffed to address all of the resulting bug reports.  The other side of this of course is that like all software projects, it simply isn’t possible to fix every single bug.  It is not fair to form hard conclusions on this until we have reviewed all the bugs in NEW and performed better analysis of the data.

The primary focus and work of the bug triage team (aka Bug Zappers) so far has been the following:

  • Closing bugs that pertain to release no longer maintained
  • Establishing a clear life cycle for the handling of bugs which includes rebasing rawhide bugs at GA and auto-closing bugs open for unmaintained releases (described here).
  • Updating documentation and getting started guides
  • Triaging bugs in states of NEW or NEEDINFO
  • Triaging important rawhide bugs for Fedora 9
  • Triaging bugs for the gcc4.3 mass rebuild.

The job of the triage team in the near term is very simple:

  1. Perform a sanity review bugs in a state of NEW and change their state as appropriate
  2. Review bugs in a state of NEEDINFO for more than 30 days to see what the next step should be

The easy work of auto-closing stale bugs, updating documentation, and creating clearer policies is done–now we need a lot more help from the Fedora community to help bring order to the remaining bugs that have not yet been triaged.  It is not clear to me how we can do a better job here.  Feel free to leave comments here or email me privately.

We had a good showing at FUDCon in January 2008, and lots of enthusiasm around some of our first IRC meetings, but since then active meeting attendance and activities around triage have dwindled significantly.  A few folks have signed up at the ActiveTriagers page, but we need more people to make this effort sustainable.  In addition we recognize that public recognition and the ability to see visible progress is key maintaining morale and researching ways to pull triage metrics from bugzilla.

Jon Stanley and I are planning a training session during the barcamp at FUDCon in Boston on June 21, 2008.  We’ll also be around on the hackfest days before working on bug triage things and participating in other events so defintely say hello and stop by if you have questions about getting started or how you can help.

If you’d like to get started with bug triage now, all the information you should need to start is here.  If you still have questions after reviewing the wiki them ask on fedora-test-list@redhat.com or ask on #fedora-qa on irc.freenode.net.  Jon Stanley is so anxious to help you he has set up a free way to call him via his blog.