SeaMonkey:Triage Week

From MozillaWiki
Revision as of 11:32, 29 November 2010 by Aqualon (talk | contribs) (Adding information about "resolving bugs")
Jump to navigation Jump to search

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.

Planning

Documents on Bug Days:

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?
  • 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-01-15 as closeme date could be reasonable.
  • 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 suggested to do 3 timeslots for Asian/Pacific (1200-1400 UTC), Europe (1900-2100 UTC) and American (0100-0300 UTC).

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?

  • Have an extra IRC channel for questions (name suggestion: #seamonkey.triage) or use #bugday?
  • 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

  • How can we judge the results of the triage week?

Categories

The triage week is divided into categories for each day, so we can focus on different components

Browser usage (Monday, 2010-12-06)

All components that are related to the usage of the browser itself.

  • Autocomplete
  • Bookmarks & History
  • Find In Page
  • Location Bar
  • Page Info
  • Search
  • Tabbed Browser

Bugzilla report 86 UNCO, 492 NEW

Security (Tuesday, 2010-12-07)

Security and safety related bugs.

  • Passwords & Permissions
  • Security

Bugzilla report 18 UNCO, 63 NEW

Operating System / Startup (Wednesday, 2010-12-08)

This category includes the components which directly affect the Operating System and the startup of SeaMonkey.

  • Download & File Handling
  • Installer
  • OS Integration
  • Session Restore
  • Startup & Profiles

Bugzilla report 43 UNCO 116 NEW

MailNews (Thursday/Friday, 2010-12-09/2010-12-10)

All components related to MailNews

  • MailNews: Account Configuration
  • MailNews: Address Book & Contacts
  • MailNews: Backend
  • MailNews: Composition
  • MailNews: General
  • MailNews: Message Display

Bugzilla report 258 UNCO 810 NEW

Help / UI (Saturday, 2010-12-11)

All components that are related to the user interface, including Help and Preferences for customizing the browser.

  • Help
  • Preferences
  • Themes
  • UI Design

Bugzilla report 69 UNCO 825 NEW

Final day (Sunday, 2010-12-12)

Sort out our "take it all" component and move the bugs to the correct components.

  • General

Bugzilla report 110 UNCO 136 NEW

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.

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