Process

First Responder (Great place to get started triaging)

When a bug first comes into Launchpad, we need to look them over to make sure that they are correct and complete. Untriaged bugs can be found by going to https://bugs.launchpad.net/people/mozillateam/+packagebugs and looking for unassigned bugs.

Assign Package

First we want to make sure that the bug has been assigned to the right package. If in doubt leave it assigned to Firefox. As more information comes in, we can always assign it to another package.

Assign Status

We need to work with the reporter to gather useful information to diagnose the issues. The easist way to do this is to reproduce the issue. Start by asking the reporter for step by step method of reproducing the issues. See if you can reproduce it on your machine.

I like to create a couple of virtual machines to match common configurations. Then, as I talk to the reporter, I set up one of the virtual machines to match the reporters. Information to ask for--

  • Ubuntu Distribution. Firefox version.
    • Type  firefox --version  on the command line.

    Types and versions of flash player. Types and version of Java.
    • Enter  about:plugins  in a firefox address bar. Goto File->Save Page As. Upload 'About Plugins' as an attachment.

    Crash Report.
    • Crash reports can be found in /var/crash.

It will take a little experience to learn what information is needed. While you are actively having a conversation with the reporter set the status to Needs Info. If you have gathered enough information to reproduce the issue set the status to confirmed. If you can not reproduce the issues set the status to Unconfirmed.

Assign Bug Reports

All issues should be assigned to "mozillateam" by default, this is part of our bug triage policy and please try to follow it as best as you can.

Tagging a Bug Report

As a team, we have decided to use a tagging library to that we can better organize our bugs. Please see MozillaTeam/BugTags for our current library. Since we have hundreds of bug reports we use various tags to organize them. For example the "traced" tag will let the team know that the bug report has debugging symbols, a full crash report, and a stack trace associated with it. As we grow as a team, we are looking to add other tags, such as "accessibility". However, we request that if you are triaging a bug please use only the tags in the library as the team must decide on any new tags.

Subscribe to Issues

If you are interested in following up on the issue subscribe to the issues. If you have set the status of a bug to "Needs info" please subscribe to it so that you can complete the information gathering dialog with the reporter.

Unconfirmed (The fun ones)

Unconfirmed Bugs These are the Red Headed Stepchildren of the bugs world. They are the issues that we can not yet reproduce or prove even happen. They are fun to pick and poke at when you have a few minutes. Every few days I like to randomly work on a few of these. After a while you will start to see patterns to solve them. They can be like those pictures were you have to unfocuse your eyes to see the ship. You can't worry about it. Sometimes you see the ship and sometimes you don't.

Needs info

Bug reports may lack some information. Triagers ask for more information from the bug reporter in order to further diagnose the problem, and set the status to "Needs Info". If you see that the bug reporter did not provide the requested information in a month or so, close the bug with a respectful message:

Your bug lacks information we would need to investigate further. We
are now going to close the bug - please reopen if you have more
information at hand.

Source

Confirmed (Name dropping for Nerds)

At this point we have to make a decision. Patch it, or push it upstream, provided that we are sure it is not specific to Ubuntu and that we can not patch it ourselves.


CategoryMozillaTeam, CategoryBugSquad

MozillaTeam/Bugs/Triage/Process (last edited 2008-08-06 17:00:00 by localhost)