What to do and what not to do in Bugzilla

  • Revision slug: What_to_do_and_what_not_to_do_in_Bugzilla
  • Revision title: What to do and what not to do in Bugzilla
  • Revision id: 56305
  • Created:
  • Creator: Napolj2
  • Is current revision? No
  • Comment /* Editbugs privilege */ fixed broken link

Revision Content

This document covers the use of Bugzilla privileges to triage bugs. It explains what should and what should not be done in bugzilla.mozilla.org.

Getting/Upgrading Bugzilla privileges

If you want to get Bugzilla privileges (as described below) mail Gerv. If he doesn't react within two weeks, ask on IRC. The conditions for getting Bugzilla privileges are also listed on Gerv's page.

Canconfirm privilege

The canconfirm privilege allows you to confirm bugs and also to start your bug reports in the confirmed state (NEW).

Confirming unconfirmed bugs

Reporting new bugs

You should report a bug in the NEW state after going through the triaging process as described in the two above-mentioned guides.

You should look at all the open bugs you've reported (see the "My Bugs" link at the bottom of every Bugzilla page) at least every two months and test whether they still exist.

Editbugs privilege

The more powerful editbugs privilege gives you the privileges of canconfirm and also the ability to edit most aspects of a bug. Therefore, don't abuse your privileges.

Resolving bugs

Some general rules:

  • When you resolve a bug, CC yourself so that you are informed when new facts come up.
  • The conditions for not resolving a bug always overrule the conditions for resolving a bug.
  • When in doubt about resolving a bug, leave it alone!
Resolving bugs as DUPLICATE

See this guide for screening DUPLICATE bugs. In general newer bugs should be marked as DUPLICATEs of older bugs, except when the newer bug contains more information (bug description clearer, patch already attached, lots of people already CC'ed, etc.).

Resolving bugs as WORKSFORME

You can resolve a bug as WORKSFORME (WFM) if it can't be reproduced on the reported hardware/OS.

You should not resolve a bug as WFM if:

  • the bug reporter uses a different hardware/operating system (e.g. bug appears on Linux and you can't reproduce it on Windows).
  • the bug has been reproduced by some people but can't be reproduced by other people.

In general you can resolve a bug as WFM if:

  • three or more people with a similar/the same setup can't reproduce the bug and the bug is only seen by the bug reporter. In this case you shouldn't just mark it WFM instantly, but ask the reporter for more details first. When marking it WFM you should tell the bug reporter that he should reopen the bug if he can still see it with a recent build.
  • the build the bug is reported against is more than one stable release old and the bug can't be reproduced with a current build.
  • the bug reporter has not responded to questions for one month and the bug can't be reproduced with a current build.
  • the bug reporter reports that he can no longer see the bug and no other people report that they are still seeing the bug.
Resolving bugs as INVALID

You should resolve a bug as INVALID, if the issue described in the bug is clearly not a Mozilla bug or if the issue is intended behaviour. The exception are bugs in other software which we have to work around. Bugs covering this exception should not be INVALIDated by anyone other than the module owner or module peer. Reports of problems with websites that result from bad coding or use of proprietary technology should also not be INVALIDated, but instead moved to the Tech Evangelism product.

Resolving bugs as FIXED

Resolve a bug as FIXED if the bug has been fixed by a checkin into the Mozilla {{template.Abbr("CVS", "Concurrent Versioning System")}} code repository. Bugs which can no longer be reproduced should be marked WORKSFORME instead of FIXED if they can't be linked to a single checkin.

Resolving bugs as WONTFIX

Bugs should not be marked WONTFIX by the normal bug triager. The decision to mark a bug WONTFIX is reserved for module owners or module peers.

Verifying bugs

You should verify a bug if it has been proven that the resolution of the bug was correct. When verifying a bug, you should remember the following:

  • Verifying DUPLICATEs is the easiest task, so start with that. Note that in general it's impossible to verify a DUPLICATE until the original has been resolved.
  • Verifying WONTFIX or INVALID bugs is relatively easy if a developer or a trusted {{template.Abbr("QA", "Quality Assurance")}} person has WONTFIXed or INVALIDated them. Bugs that were INVALIDated or WONTFIXed by someone else must be verified by a module owner or module peer or someone who has been explicitly told by a module owner or module peer that they are able to do so for that module.
  • Before verifying FIXED bugs, make sure that you can verify them on every hardware/OS they were reported on. If that's impossible, try to cooperate with multiple people to verify the bug.
  • There are no clear rules for verifying WORKSFORME. In general you should make sure that the bug has been resolved for a few months and no complaints about the resolution have come up.

Changing the bug information fields

Summary

You should change the summary if the current one is unclear or does not correctly describe the issue covered by the bug. You should not change the summary in order to morph the bug to describe a different issue. In this case the bug should be resolved and another bug should be opened.

OS/Hardware

Make sure that the OS or Hardware fields correctly display the systems that are affected. If a bug is Windows-only, change the field to the oldest affected operating system. If the bug is present on Linux and Windows, change the fields to Hardware = PC and OS = ALL. If another hardware platform like Mac or DEC is also affected, change Hardware to ALL.

Severity

See this description for an overview of the different bug severities.

The blocker severity should be used very seldomly, because only a fraction of the hundreds of thousands bugs really block the development of mozilla and these are normally fixed very quickly. As a result, bugs which are UNCONFIRMED for more than a few days do not qualify for the blocker severity. The exception to this rule are platform-specific or compiler-specific bugs. Basically, anything that prevents builds from building, running, or being used for dogfood (able to use Bugzilla, tinderbox, lxr, etc.) is a blocker.

Bug reports about crashes, hangs, dataloss, or severe security exploits (e.g. remote execution of arbitrary code) get the critical severity.

Priority/Target Milestone

As stated in the Bugzilla Etiquette, you must not change the Target Milestone and Priority fields. These fields are reserved for the developers. This also applies to bugs with Target Milestones in the past.

Reassigning bugs

If a bug belongs to a different Product or Component it should be reassigned. When performing bug reassignments, keep the following things in mind:

  • Always remember to check the Reassign to default owner and QA Contact radio button under the comment textbox.
  • Mozilla applications like the Application Suite, Thunderbird, or Firefox share most of their program code and all of the backend code including things like network connectivity (FTP, HTTP, IMAP) and HTML rendering. Make sure that you also test Thunderbird or Firefox bugs with the Application Suite and move the bug to one of the core products, if the bug also exists in the Application Suite.
  • If you don't know where a bug belongs, don't touch it! For example, don't move bugs into the JS engine Component unless you really know they are JS engine bugs, and don't leave bugs in the JS engine Component if you know that the malfunction being described is a DOM problem.

Bug flags

Mozilla drivers use flags to identify bugs blocking a release. You may only use the blocking? flag to nominate bugs for blocking status. The use of the blocking- flag and the blocking+ flag is prohibited. Continued abuse will result in revocation of your Bugzilla privileges.

Mass changes

Mass changes (changes to more than one bug simultaneously) are discouraged. Don't do it!

Original Document Information

  • Author(s): Simon Paquet
  • Other Contributors: Andreas Kunz, Boris Zbarsky, Christian Biesinger, Daniel Wang, Fantasai, Ian Hickson, James Graham, and Michael Lefevre

Revision Source

<p>This document covers the use of Bugzilla privileges to triage bugs. It explains what should and what should not be done in <a class="external" href="https://bugzilla.mozilla.org/">bugzilla.mozilla.org</a>.
</p>
<h3 name="Getting.2FUpgrading_Bugzilla_privileges"> Getting/Upgrading Bugzilla privileges </h3>
<p>If you want to get Bugzilla privileges (as described below) mail <a class="external" href="http://www.gerv.net/hacking/before-you-mail-gerv.html">Gerv</a>. If he doesn't react within two weeks, ask on <a class="external" href="irc://irc.mozilla.org/mozilla">IRC</a>. The conditions for getting Bugzilla privileges are also listed on <a class="external" href="http://www.gerv.net/hacking/before-you-mail-gerv.html">Gerv's page</a>.
</p>
<h3 name="Canconfirm_privilege"> Canconfirm privilege </h3>
<p>The canconfirm privilege allows you to confirm bugs and also to start your bug reports in the confirmed state (NEW).
</p>
<h4 name="Confirming_unconfirmed_bugs"> Confirming unconfirmed bugs </h4>
<ul><li> A useful <a class="external" href="http://www.mozilla.org/quality/help/unconfirmed.html">general guide for confirming unconfirmed bugs</a>.
</li><li> A <a class="external" href="http://groups.google.com/groups?selm=mailman.1069274340.867.mozilla-layout%40mozilla.org">guide for confirming layout bugs</a> (bugs in web page rendering)
</li></ul>
<h4 name="Reporting_new_bugs"> Reporting new bugs </h4>
<p>You should report a bug in the NEW state after going through the triaging process as described in the two above-mentioned guides.
</p><p>You should look at all the open bugs you've reported (see the "My Bugs" link at the bottom of every Bugzilla page) at least every two months and test whether they still exist.
</p>
<h3 name="Editbugs_privilege"> Editbugs privilege </h3>
<p>The more powerful editbugs privilege gives you the privileges of <a class="external" href="http://developer.mozilla.org/en/docs/What_to_do_and_what_not_to_do_in_Bugzilla#Canconfirm_privilege">canconfirm</a> and also the ability to edit most aspects of a bug. Therefore, don't abuse your privileges.
</p>
<h4 name="Resolving_bugs"> Resolving bugs </h4>
<p>Some general rules:
</p>
<ul><li> When you resolve a bug, CC yourself so that you are informed when new facts come up.
</li><li> The conditions for <b>not resolving</b> a bug always overrule the conditions for resolving a bug.
</li><li> When in doubt about resolving a bug, leave it alone!
</li></ul>
<h5 name="Resolving_bugs_as_DUPLICATE"> Resolving bugs as <code>DUPLICATE</code> </h5>
<p>See this <a class="external" href="http://www.mozilla.org/quality/help/screening-duplicates.html">guide for screening <code>DUPLICATE</code> bugs</a>. In general newer bugs should be marked as <code>DUPLICATE</code>s of older bugs, except when the newer bug contains more information (bug description clearer, patch already attached, lots of people already CC'ed, etc.).
</p>
<h5 name="Resolving_bugs_as_WORKSFORME"> Resolving bugs as <code>WORKSFORME</code> </h5>
<p>You can resolve a bug as <code>WORKSFORME</code> (WFM) if it can't be reproduced on the reported hardware/OS.
</p><p>You <b>should not</b> resolve a bug as WFM if:
</p>
<ul><li> the bug reporter uses a different hardware/operating system (e.g. bug appears on Linux and you can't reproduce it on Windows).
</li><li> the bug has been reproduced by some people but can't be reproduced by other people.
</li></ul>
<p>In general you can resolve a bug as WFM if:
</p>
<ul><li> three or more people with a similar/the same setup can't reproduce the bug and the bug is only seen by the bug reporter. In this case you shouldn't just mark it WFM instantly, but ask the reporter for more details first. When marking it WFM you should tell the bug reporter that he should reopen the bug if he can still see it with a recent build.
</li><li> the build the bug is reported against is more than one stable release old and the bug can't be reproduced with a current build.
</li><li> the bug reporter has not responded to questions for one month and the bug can't be reproduced with a current build.
</li><li> the bug reporter reports that he can no longer see the bug and no other people report that they are still seeing the bug.
</li></ul>
<h5 name="Resolving_bugs_as_INVALID"> Resolving bugs as INVALID </h5>
<p>You should resolve a bug as <code>INVALID</code>, if the issue described in the bug is clearly not a Mozilla bug or if the issue is intended behaviour. The exception are bugs in other software which we have to work around. Bugs covering this exception should not be <code>INVALID</code>ated by anyone other than the <a class="external" href="http://www.mozilla.org/owners.html">module owner or module peer</a>. Reports of problems with websites that result from bad coding or use of proprietary technology should also not be <code>INVALID</code>ated, but instead moved to the Tech Evangelism product.
</p>
<h5 name="Resolving_bugs_as_FIXED"> Resolving bugs as <code>FIXED</code> </h5>
<p>Resolve a bug as <code>FIXED</code> if the bug has been fixed by a checkin into the Mozilla {{template.Abbr("CVS", "Concurrent Versioning System")}} code repository. Bugs which can no longer be reproduced should be marked <code>WORKSFORME</code> instead of <code>FIXED</code> if they can't be linked to a single checkin.
</p>
<h5 name="Resolving_bugs_as_WONTFIX"> Resolving bugs as WONTFIX </h5>
<p>Bugs should not be marked <code>WONTFIX</code> by the normal bug triager. The decision to mark a bug <code>WONTFIX</code> is reserved for module owners or module peers.
</p>
<h4 name="Verifying_bugs"> Verifying bugs </h4>
<p>You should verify a bug if it has been proven that the resolution of the bug was correct. When verifying a bug, you should remember the following:
</p>
<ul><li> Verifying <code>DUPLICATE</code>s is the easiest task, so start with that. Note that in general it's impossible to verify a <code>DUPLICATE</code> until the original has been resolved.
</li><li> Verifying <code>WONTFIX</code> or <code>INVALID</code> bugs is relatively easy if a developer or a trusted {{template.Abbr("QA", "Quality Assurance")}} person has <code>WONTFIX</code>ed or <code>INVALID</code>ated them. Bugs that were <code>INVALID</code>ated or <code>WONTFIX</code>ed by someone else must be verified by a module owner or module peer or someone who has been explicitly told by a module owner or module peer that they are able to do so for that module.
</li><li> Before verifying <code>FIXED</code> bugs, make sure that you can verify them on every hardware/OS they were reported on. If that's impossible, try to cooperate with multiple people to verify the bug.
</li><li> There are no clear rules for verifying <code>WORKSFORME</code>. In general you should make sure that the bug has been resolved for a few months and no complaints about the resolution have come up.
</li></ul>
<h4 name="Changing_the_bug_information_fields"> Changing the bug information fields </h4>
<h5 name="Summary"> Summary </h5>
<p>You should change the summary if the current one is unclear or does not correctly describe the issue covered by the bug.  You <b>should not change</b> the summary in order to morph the bug to describe a different issue. In this case the bug should be resolved and another bug should be opened.
</p>
<h5 name="OS.2FHardware"> OS/Hardware </h5>
<p>Make sure that the OS or Hardware fields correctly display the systems that are affected. If a bug is Windows-only, change the field to the oldest affected operating system. If the bug is present on Linux and Windows, change the fields to Hardware = PC and OS = ALL. If another hardware platform like Mac or DEC is also affected, change Hardware to ALL.
</p>
<h5 name="Severity"> Severity </h5>
<p>See <a class="external" href="http://bugzilla.mozilla.org/bug_status.html#severity">this description</a> for an overview of the different bug severities.
</p><p>The blocker severity should be used very seldomly, because only a fraction of the hundreds of thousands bugs really block the development of mozilla and these are normally fixed very quickly. As a result, bugs which are <code>UNCONFIRMED</code> for more than a few days do not qualify for the blocker severity. The exception to this rule are platform-specific or compiler-specific bugs. Basically, anything that prevents builds from building, running, or being used for dogfood (able to use <a class="external" href="https://bugzilla.org/">Bugzilla</a>, <a class="external" href="http://tinderbox.mozilla.org/">tinderbox</a>, <a class="external" href="http://lxr.mozilla.org/">lxr</a>, etc.) is a blocker.
</p><p>Bug reports about crashes, hangs, dataloss, or severe security exploits (e.g. remote execution of arbitrary code) get the critical severity.
</p>
<h5 name="Priority.2FTarget_Milestone"> Priority/Target Milestone </h5>
<p>As stated in the <a class="external" href="http://bugzilla.mozilla.org/page.cgi?id=etiquette.html">Bugzilla Etiquette</a>, you must not change the Target Milestone and Priority fields. These fields are reserved for the developers. <b>This also applies to bugs with Target Milestones in the past.</b>
</p>
<h4 name="Reassigning_bugs"> Reassigning bugs </h4>
<p>If a bug belongs to a different Product or Component it should be reassigned. When performing bug reassignments, keep the following things in mind:
</p>
<ul><li> Always remember to check the <b>Reassign to default owner and QA Contact</b> radio button under the comment textbox.
</li><li> Mozilla applications like the <a class="external" href="http://www.mozilla.org/releases/">Application Suite</a>, <a class="external" href="http://www.mozilla.org/projects/thunderbird/">Thunderbird</a>, or <a class="external" href="http://www.mozilla.org/projects/firefox/">Firefox</a> share most of their program code and all of the backend code including things like <a class="external" href="http://www.mozilla.org/projects/necko/">network connectivity</a> (FTP, HTTP, IMAP) and <a class="external" href="http://www.mozilla.org/projects/nglayout/">HTML rendering</a>. Make sure that you also test Thunderbird or Firefox bugs with the Application Suite and move the bug to one of the core products, if the bug also exists in the Application Suite.
</li><li> If you don't know where a bug belongs, don't touch it!  For example, don't move bugs into the JS engine Component unless you really know they are JS engine bugs, and don't leave bugs in the JS engine Component if you know that the malfunction being described is a DOM problem.
</li></ul>
<h4 name="Bug_flags"> Bug flags </h4>
<p>Mozilla <a class="external" href="http://www.mozilla.org/about/roles.html#Drivers">drivers</a> use flags to identify bugs blocking a release. You may only use the <code>blocking?</code> flag to nominate bugs for blocking status. The use of the <code>blocking-</code> flag and the <code>blocking+</code> flag is <b>prohibited</b>. Continued abuse will result in revocation of your Bugzilla privileges.
</p>
<h4 name="Mass_changes"> Mass changes </h4>
<p>Mass changes (changes to more than one bug simultaneously) are discouraged. Don't do it!
</p>
<div class="originaldocinfo">
<h3 name="Original_Document_Information"> Original Document Information </h3>
<ul><li> Author(s): Simon Paquet
</li><li> Other Contributors: Andreas Kunz, Boris Zbarsky, Christian Biesinger, Daniel Wang, Fantasai, Ian Hickson, James Graham, and Michael Lefevre
</li></ul>
</div>
Revert to this revision