Include(MozillaTeam/Header)

Introduction

A bugs status should only be modified according to this definition. Usually non-team members are discouraged to change states on their own without reading this document fully, it outlines the correct procedures that are in place to triage a bug successfully.

Please keep in mind that if a user does not know about this document, try to 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 lifetime. 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.

New

Bugs in the state 'New'.

Aliases

• Initial Contact
• Screening
• Categorization

Description

Bugs are initially submitted in an 'New' state, these bugs have not yet been screened or categorized at all.

Goals

• Minimize the 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, eg. '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.

Incomplete

Aliases

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

Description

Bugs that require input from the reporter or more work from the MozillaTeam in order to complete a report which is useful for developers who process it in the 'confirmed' state. There are several paths through the Incomplete 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 duplicate search and if the bug's state looks fine, move the bug onto Confirmed.

• 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 it's actually a request that would need change to the upstream code base. For packaging enhancement the confirmer will review if they are reasonable and move them to Confirmed. For a new upstream feature we often do not have the time to report it upstream, we will only the pursue most worthy, (in our eyes), enhancement ourselves. Others will be moved to the Rejected state.

• 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 MozillaTeam - who will be at hand for further requests on this bug, like testing potential fixes, etc. This bug then gets tagged mt-confirm to show that it might be ready for the Confirmed state.

As you might have noticed, all bugs eventually end up with the tag mt-confirm, from there they will either be moved to 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 Incomplete state and just indicates that this bug has a badly written 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 - a useful crash report from the user is needed.
  • mt-needretrace - someone to do a retrace of the crash report submitted in the bug is needed.
• For Feature Bugs:
  • mt-needtestcase - a step by step description on how to reproduce the problem is needed.
  • mt-needtester - a tester is needed which can provide responsive feedback at best in the IRC channel.
• All Bugs:
  • likely-dup - bugs that are duplicates, but triager does not have bug number of MASTER bug at hand, can be tagged 'likely-dup'. Other triagers can then pick them, find MASTER bug and mark them appropriately.
  • mt-needsummary - someone needed to clean up the issue summary before proceeding.
  • mt-confirm - this bug looks ready for "Confirmed". Someone with experience is needed review and transition it to "Confirmed" 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, these issues should be tagged 'mt-upstream'. Work to be done when tagged 'mt-upstream' includes:

• Reproducing the bug with an upstream release of Firefox or Thunderbird.
• Further the 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 the state In Progress.

For bugs that are related to packaging in Ubuntu we will evaluate the cause(s) 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 bug tracker.
• Good understanding of packaging and other general topics, like a bit of C++ coding, as well as shell scripting in order to debug and evaluate solution for Ubuntu specific issues.

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

Activities/Tags

For bugs in upstream code-base:

• mt-upstream tagged bugs need to be triaged upstream. This includes reproducing with upstream official release, then searching for potential upstream reports. 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 the In Progress state.

For bugs in the Ubuntu code-base:

• 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 the In Progress state.

• 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 MozillaTeam member who might be capable to implement the 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]