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.

NOTE: Some of the tags on this Wiki are obsolete. This will be on our meeting agenda for the next MozillaTeam meeting.

States and Uses

Each bug will more or less run through the following states in its lifetime. The goal is 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 one of the following tags, talk to us in order to find a new tag. Until we go through the tags and decide ones to keep or drop no tag is discouraged but is fine for now. this is something that will be a topic for The MozillaTeam sometime shortly.

• 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. This should be done by a MozillaTeam member or someone with Mozilla upstream experience.

Confirmed

Aliases

• Upstream Triage
• Evaluation

Description

NOTE: The most common reason for Mozilla bugs is extensions. The reason why we discourage people from changing status of bugs is due to this reason. 2 ways that should be used to confirm a bug is if there is an upstream bug reported or report an upstream bug for your bug, however if you report the bug upstream we still can not move state to confirmed because bug reporters should never confirm their own bugs. One of the MozillaTeam members will tag it mt-upstream or comment on the bug that this should be looked for upstream and if not found to report it upstream. The other way is to have atleast one MozillaTeam member reproduce this bug atleast once.

NOTE: If you feel that the bug you are looking at should be set to confirmed state please use the mt-confirm tag. This gives the MozillaTeam a chance to look at it and try to reproduce the bug, if a member of the MozillaTeam can reproduce this bug than they can mark status as confrim, or we can than mark it as mt-upstream to verify that a bug is on the Upstream Bug Tracker. The reason we prefer to change status is that we know what it takes to fix the bug and if there is enough info on it. If you do not have an account for Upstrream Bug Tracker, Please let one of the members of the MozillaTeam, please let us know on the bug report or in #ubuntu-mozillateam on irc.freenode.net and we can than file it upstream if the bug report has the information needed for Mozilla bug tracker.

NOTE: If you need help with triaging a bug report please feel free to contact the MozillaTeam in one of 2 ways. You can normally find one of us in #ubuntu-mozillateam. You can find a list of the MozillaTeam members here MembersIf we are not there you can always let us know on our mailing list. You can find our mailing list at [ubuntu-mozillateam@lists.ubuntu.com Mailing List].

The above notes are there until The Mozilla Team can set up a meeting and we will work out exact procedure than. The notes above are written for Confirmed but can also be used for all other statuses.

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, CategoryBugSquad