QMO quality.mozilla.org (alpha)

Our project to lower the number of unconfirmed bugs has been very successful. A great thanks to all of our community members like stevee, aaronr, and aleksej for their help on lowering the number of unconfirmed bugs.

We have triaged a lot of bugs so far (over 1000 bugs in nearly a month!), but there is still a huge list of bugs to work on. So we still need your help!

For those community members that are new and want to help or want more information about this, please see the inital post.

There are many ways where YOU can help:

• Join #triage on irc.mozilla.org
• Join our Bugday events
• Run one of the queries below and see if you can confirm or resolve a bug

Some more information about Triaging Bugs:

How to Triage Bugs

Our goal is to triage bugs as fast as possible but with a high amount of quality. While we do want to lower the total unconfirmed bug count, we don't want to do so at the cost of
losing valid bug reports. The risk to miss a real problem
is too high. Take as long as you need to triage a bug. This is
not a race.

You don't need developer skills to triage bugs however, some understanding of bugzilla and what bugs already exist can be a good thing. When in doubt, ask.

The first step to triage bugs is testing/reproducing the initial bug report.

• If you can't reproduce a bug or you think that some steps to reproduce
  are missing, ask the reporter in the bug. A good comment will also help the next triager understand the status of the bug.
• If you need more information, ask the reporter in the bug.
• If you are unsure what do to with a bug, ping Sam (ss) or
  Carsten (tomcat) on irc. Or cc Sam and Carsten to the bug (enter :sps,
  :tomcat into the CC field in Bugzilla). Be sure to leave a comment when you CC them so they know what to look at.

Okay. I can reproduce this bug, what's next?

First, make sure you tested the same configuration the reporter had. That includes their operating system as well as what version of Firefox they're using. If you're able to reproducing using Firefox 2.0.0.4 but not the latest trunk build of Firefox, there's a good chance the bug has been fixed. If you think that's the case, ask the reporter if they agree.

Next, check for duplicates -- a lot of bugs are already
filed. If you find an appropriate bug you can ask someone in #triage to
close the bug, or leave a comment in this bug and CC Sam and Carsten (see above) to the bug.

When you can confirm a bug, include as much information as possible for developers (such as, steps to reproduce, what version of the browser this reproduces with, etc). If you need
someone that can confirm this bug - leave a comment in this bug with
all possible information and ping ss or tomcat - or any other moderator
in #triage.

I have requested information from a reporter long ago
but never got a response / I have found a bug where steps to reproduce
are missing and there has been no feedback from the reporter.

• Try to
  reproduce every bug. No response or update from a reporter doesn't mean the bug report isn't important. In every case, try and reproduce the bug as reported.
• After testing, if you absolutely need more information to reproduce, you may close the bug as INCOMPLETE. Just be sure to test the bug beforehand so that we can ensure no bug slips under the radar.

Crash Bugs:

Since Firefox crashing is bad user experience,
bugs which report crashes are considered critical. For crash bugs we set the severity of the bug to "critical" and add the "crash" keyword.

Crash reports are very sensitive compare to other bugs. If you
are not able to reproduce a crash (and you are on the same platform as it was reported on) and/or more information is missing (like a Talkback ID or steps
to reproduce), please ask the reporter of this bug via a comment in the bug. Also ask if the reporter is able to reproduce this in a latest release and/or a
recent trunk build.

For bugs which report a crash, we typically need a testcase and/or steps to reproduce as well as a Talkback ID. If a Talkback ID is missing, it's important to ask the reporter to provide one.

Please don't resolve a crash bug if you are not sure or have doubts about the resolution. You can always cc ss (Sam) and Tomcat (Carsten) to bug.

You can do this in Bugzilla by entering the following into the cc field:

:sps, :tomcat

What about bugs that "work for me" but have no feedback over a long period of time?

If you are triaging a bug that you are unable to reproduce ("works for me") on the same plattform
(e.g., a bug reported on Linux is also being tested on Linux) or you don't see enough steps
to reproduce, add a comment to this bug asking if this also no longer a
problem for the bug reporter. When you do this, please add a "CLOSEME" whiteboard status as well in this format:

CLOSEME mm/dd

In the above, 'mm' stands for the month and 'dd' for the day. Please add a minimum of 2 weeks between now and your CLOSEME date, to give the reporter a chance to respond to your question. For example, if you're commenting in a bug on July 1, set the 'CLOSEME' status like this: CLOSEME 07/15

We use the CLOSEME status to check for feedback, closing bugs if there hasn't been any.

Do you need help? Have more questions?

Ping ss or tomcat in #triage on irc.mozilla.org or ping one of the other moderators there. Alternatively, on bugs, you can CC tomcat and ss; see above for information on how.

In every case, please include as much information as possible in your comment in
the bug, this will help other triagers who might pass by and will also help the developers fix the
bug.

Again many thanks for your help in lowering the number of unconfirmed bugs in Firefox!