Triage Week

The problem: our bug list

The idea: do a triage week to get the number of UNCONFIRMED bugs down and see which of the NEW bugs are still an issue.

How to help?

You can find detailed information on how to participate and the schedule of the triage week on the Triage Week Guide page.

Planning

Documents on Bug Days:

• Bug Day, Bug Day Planner
• TB Bugdays, TB Bugdays Planning

When?

Suggested Date: Week from 2010-12-06 to 2010-12-13 (CW 49)

Goals

• Resolve bugs which aren't an issue anymore
  • Dupe bugs against the bugs with the fixes
• Mark UNCO bugs that can be reproduced as NEW

Open Questions

• Should we limit it to a certain component (last bug day: General), only new bugs, ..., or a different one each day?
  • Limitation to certain components is a good idea, probably we should make it dependent on when people familiar with a component have time to be on IRC.
  • => see SeaMonkey:Triage_Week#Categories
• Who decides about what bugs are INVALID/WONTFIX?
  • Ask component owners? Ask experienced community members ("champions")?
  • -> Use a wontfix? whiteboard marker?
  • -> Use needs-resolution whiteboard marker?
  • => see SeaMonkey:Triage_Week#Resolving_Bugs
• What to do with incomplete bugs?
  • Ask the bug reporter for further information and set a closeme-date?
  • -> Use a closeme whiteboard marker
  • => see SeaMonkey:Triage_Week#Resolving_Bugs
• How much time to give bug reporters for delivering further information?
  • -> We probably can't expect much to be done during Christmas holiday season, so using 2011-02-01 as closeme date could be reasonable and easy to remember.
• Do we have the man power to do a whole bug day or should we announce a certain time window where champions are likely to be present?
  • -> Tony mentioned the 3 timeslots the Thunderbird guys will be using on Dec. 2 for their "Finding dupes" workshop, namely Asia/Pacific (1200-1400 UTC), Europe / Africa / Near East (1900-2100 UTC) and the Americas [from Alaska to Tierra del Fuego ;-) ] (0100-0300 UTC). We might do something similar.

How to get the community involved?

• Post in the newsgroups (mozilla.dev.apps.seamonkey and mozilla.support.seamonkey)
• Blogposts to appear at planet.m.o (SeaMonkey blog, KaiRo?, anyone else? QMO?)
• Post at MozillaZine
• Any other ways to announce it?

How can we support triagers?

• Use #seamonkey as support channel on IRC
• What extra resources do we need? Are links to QA/Triage and Thunderbird:Bug_Triage sufficient? Do we have to describe those steps specific for SeaMonkey on an extra page?
• Who can give canconfirm/editbugs rights to people who want to contribute? Or should devs resolve the bugs if somebody without those rights wants to help?

Aftermath

• See Status Meeting 2010-12-14 report.

Categories

For the actual categories see Triage Week Guide.

Project

These components are related to the project itself, including building, releases and testing.

• Build Config
• Project Organization
• Release Engineering
• Testing Infrastructure

Bugzilla report 1 UNCO 50 NEW

Remark: Not very useful to do a community bugday for that

The Missing Ones

• Composer
• Sidebar

What's the progress of integrating Kompozer respectively rewriting the Sidebar? Does it make sense to triage that components at the moment?

Bugzilla report 108 UNCO 186 NEW

Resolving Bugs

The goal is to resolve bugs, i.e. mark valid UNCO bugs as NEW, dupe them against known bugs and so on. For those bugs which are not clear, there are several whiteboard markers that can be used.

[CLOSEME yyyy-mm-dd INCO] The bug report is incomplete and should be closed if the reporter doesn't add further information until yyyy-mm-dd.

[CLOSEME yyyy-mm-dd WFM] The bug can't be reproduced with a current SeaMonkey nightly and should be closed on yyyy-mm-dd if the bug reporter doesn't say otherwise.

[CLOSEME INVA/WONT?] This marker can be used for bugs that could be INVALID or WONTFIX and the owner of the component or somebody familiar with it has to decide what to do with it.

• The following documents can help you find who are the owner and peers of a given component:
  • The SeaMonkey "Project Areas" page
  • The MozillaWiki Modules page, and in particular:
    • Modules/SeaMonkey
    • Modules/Core
    • Modules/Toolkit
    • Modules/MailNews Core
  • The "Bugzilla Components / Modules" Google spreadsheet
• Beware that some of these documents list for some people email addresses different from their Bugzilla address-of-record.

DUPEME This marker can be used for bugs where an older bug report with the same issue has been seen, but can't be found at the moment.