Wiki edit: BugStates Procedures

[asac]: draft for discussion - still a stub

Introduction

Bug state should only be modified according to this definition.

Usually non-team-members are discouraged to change states on their own without getting in contact with the MozillaTeam first.

In case a user does not know about this document, be nice. For instance, if a MozillaTeam member recognizes that a user did wrongly confirm a bug, point him to this document and fix the state again.

States and Uses

Each bug will more or less run through the following states in its life. The goal be to make all bugs eventually end up in one of our two final states:

• Rejected - the bug could not be processed
• Fix Released - the bug has been fixed

Unconfirmed

Bugs in state 'unconfirmed'

Aliases

• Initial Contact
• Screening
• Categorization

Description

Bugs are initially submitted in state 'unconfirmed'. Unconfirmed bugs have not yet been screened and categorized successfully.

Goals

• Minimize initial response time
• Categorize to initiate workflow in the proper direction
• Filter obvious duplicates
• Deliver an initial professional support experience for the bug reporter
• Fix bad bug titles (like 'firefox crashes') if more information is available in bug description

Skill Level Requirements

• No first timer
• To properly initiate the bug workflow you need a good understanding of the ["MozillaTeam/Bugs/Procedures"]
• For duplicate detection you need the more or less bug picture of bugs already reporter

Activities/Tags

• <none> - Absence of a state tag indicates that the bug has not yet been triaged

Needs Info

Aliases

• Gathering Information, Crash Traces, Testcase
• Reproduce and find Tester

Description

Bugs that require input from the user or more work from MozillaTeam in order to make a bug useful for processing in state 'confirmed' are set to state 'needs info'. There are several paths through the Needs Info state:

• Crashers start in mt-needreport tag if they don't have a proper crash report attached; as soon as a report is available they get tagged mt-needretrace; as soon as symbolized report is available they get tagged mt-confirm. Then a confirm-triager will eventually show up and review the report, do an initial dupliate search and if the bugs state looks fine, move the bug to Confirmed state.

• Wishlist directly get tagged mt-confirm. The triager has then to figure out if this enhancement is related to how we package things or if its actually a request that would need change to upstream code base. For packaging enhancement the confirmer will review if they are reasonable and move them to State Confirm. For new upstream feature, only the best enhancement should be submitted upstream. Other will be denied and move to state Rejected.

• Feature Bugs go through a generic workflow. First we need a good testcase to reproduce a bug. This will be indicated by the mt-needtestcase tag. As soon as there is such a testcase available, mt-needtester can be used to indicate that we need a responsive tester - e.g. member of mozilla team - who will be at hand for further requests on this bug, like testing potential fixes, etc. Then this bug gets tagged mt-confirm to show that it might be ready for state Confirmed.

As you might have noticed, all bugs eventually end up with tag mt-confirm. From there they will either be moved to state Confirmed by a confirmer or they will be bounced back - properly tagged - with new instruction on what what info is missing to get Confirmed.

The mt-needsummary tag can be used throughout the whole Needs Info state and just indicates that this bug has a bad summary or description which should be fixed before it can be Confirmed.

Goals

• Gather information needed to properly process the bug in state 'confirmed'
• Improve bug title and description with input from reporter
• Get fully traced crash reports for crashers bugs
• Identify testcases to reproduce feature bugs

• Reproduce feature bug testcases. At best the tester would be someone in the MozillaTeam or someone else who is responsive upon request - at best regularly lurking on IRC.

• Filter duplicates as discussion and description of a bug evolves.

Skill Level Requirements

• We have tasks for beginners as well as more experienced bug triagers here.

Activities/Tags

(See ["MozillaTeam/Bugs/Tags"] for a detailed description on tags, their meaning as well as typical actions associated with them)

• <none> - this is illegal, aka a triage bug: state need info always needs one of the tags below. If there is a bug that does not fit, talk to us in order to find a new one.

• For Crashers:
  • mt-needreport - we need a useful crash report from the user
  • mt-needretrace - we need someone to do a retrace of not yet processed crash report submitted in the bug
• For feature bugs:
  • mt-needtestcase - we need a step by step description on how to reproduce
  • mt-needtester - we need a tester which can provide responsive feedback at best in irc channel
• All bugs:
  • mt-needinfo - we need additional information before proceeding with bug evaluation. (please try to figure out what tag is missing if you feel tempted to use this tag
  • mt-needsummary - we need someone to clean up the issue summary before proceeding.
  • mt-confirm - this bug looks ready for state "Confirm". Someone with experience review and transition to state "Confirm" if this report is fine.

Confirmed

Aliases

• Upstream Triage
• Evaluation

Description

A bug that contains all information needed to reproduce and submit upstream or to evaluate a solution on our own is set to state Confirmed.

For bugs that are not related to the way we package them, they should be triaged upstream. Bugs like this will be tagged 'mt-upstream'. Work to be done when tagged 'mt-upstream' includes reproducing with upstream release of firefox or thunderbird. Further an initial search for matching existing upstream bugs should be performed. If this is done, the bug gets tagged mt-postupstream. Bugs tagged like that should be posted upstream before they get tagged mt-confirm which indicates that a bug needs to be confirmed by upstream before we can move the ubuntu bug to state In Progress.

For bugs that are related to packaging in ubuntu, we will evaluate the reasons of the problem and post a good description on how a solution might be implemented. Bugs that lack a good evaluation of potential solutions are tagged mt-eval.

Goals

• find a proper upstream bug
• submit a new upstream bug
• evaluate solutions on how to fix an ubuntu/packaging bug

Skill Level Requirements

• experienced on how to use upstream bugtracker
• good understanding of packaging and other general topics, like a bit c++ coding, as well as shell scripting in order to debug and evaluate solution for ubuntu specific issues.

• good knowledge of team members capabilites, so bugs can be properly assigned when moving on to state In Progress.

Activities/Tags

For bugs in upstream codebase:

• mt-upstream tagged bugs need to be triaged upstream. This includes reproducing with upstream official release, then searching multiple times for potential already known upstream issues. If that is done and there is no upstream bug available tag the bug mt-postupstream.

• mt-postupstream bugs are ready for upstream submission. Verify for a last time that this bug is not known upstream and then submit a new bug.

• mt-confirm bugs that are submitted upstream, but are not yet confirmed should be marked that way. This allows bug triagers with appropriate permissions to confirm bugzilla bugs in case this has not yet done. Confirmed upstream bugs are then moved to state In Progress.

For bugs in the ubuntu codebase:

• mt-eval bug needs evaluation. When this is done, the bug gets tagged mt-confirm to show that this bug has a proper solution attached and someone with the will to implement the fix can move it to state In Progress.

• mt-confirm tags bugs that have a good solution evaluation attached. The confirmer will once again review that evaluation and move the bug to In Progress while assigning this bug to a mozilla team member who might be capable to implement a solution.

In Progress

Aliases

• bug fixing

Description

Bug is processed upstream or we are currently implementing a solution.

Goals

Skill Level Requirements

Activities/Tags

Fix Committed

Aliases

• testing

Description

Bug has a fix submitted, which can be tested upstream or in a MozillaTeam/PreviewPackage.

Goals

• verify the fix corrects the initially reported problem
• verify the fix causes no regressions

Skill Level Requirements

Activities/Tags

• needtesting

Fix Released

Bug fix has been released as an official package to ubuntu distribution archive.

[:CategoryMozillaTeam]