SeaMonkey:Triage Week

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:

• 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?
• What to do with incomplete bugs?
  • Ask the bug reporter for further information and set a closeme-date?
  • -> Use a closeme whiteboard marker
• 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?

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