diff options
Diffstat (limited to 'confirmhelp.html')
| -rw-r--r-- | confirmhelp.html | 49 |
1 files changed, 32 insertions, 17 deletions
diff --git a/confirmhelp.html b/confirmhelp.html index 1dad97302..20ccfd402 100644 --- a/confirmhelp.html +++ b/confirmhelp.html @@ -1,4 +1,5 @@ -<HTML><head> +<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd"> +<html><head> <!-- The contents of this file are subject to the Mozilla Public @@ -21,15 +22,18 @@ Contributor(s): Terry Weissman <terry@mozilla.org> --> +<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> <title>Understanding the UNCONFIRMED state, and other recent changes</title> </head> <body> <h1>Understanding the UNCONFIRMED state, and other recent changes</h1> +<p> [This document is aimed primarily at people who have used Bugzilla before the UNCONFIRMED state was implemented. It might be helpful for newer users as well.] +</p> <p> @@ -39,60 +43,67 @@ bug is real. Very busy engineers will probably generally ignore UNCONFIRMED that have been assigned to them, until they have been confirmed in one way or another. (Engineers with more time will hopefully glance over their UNCONFIRMED bugs regularly.) +</p> <p> - The <a href="bug_status.html">page describing bug fields</a> has been updated to include UNCONFIRMED. -<p> +</p> +<p> There are two basic ways that a bug can become confirmed (and enter the NEW) state. +</p> <ul> <li> A user with the appropriate permissions (see below for more on permissions) decides that the bug is a valid one, and confirms it. We hope to gather a small army of responsible volunteers - to regularly go through bugs for us. - <li> The bug gathers a certain number of votes. <B>Any</B> valid Bugzilla user may vote for + to regularly go through bugs for us.</li> + <li> The bug gathers a certain number of votes. <b>Any</b> valid Bugzilla user may vote for bugs (each user gets a certain number of bugs); any UNCONFIRMED bug which -gets enough votes becomes automatically confirmed, and enters the NEW state. +gets enough votes becomes automatically confirmed, and enters the NEW state.</li> </ul> +<p> One implication of this is that it is worth your time to search the bug system for duplicates of your bug to vote on them, before submitting your own bug. If we can spread around knowledge of this fact, it ought to help cut down the number of duplicate bugs in the system. +</p> <h2>Permissions.</h2> +<p> Users now have a certain set of permissions. To see your permissions, check out the <a href="userprefs.cgi?bank=permissions">user preferences</a> page. +</p> <p> - If you have the "Can confirm a bug" permission, then you will be able to move UNCONFIRMED bugs into the NEW state. +</p> <p> - If you have the "Can edit all aspects of any bug" permission, then you can tweak anything about any bug. If not, you may only edit those bugs that you have submitted, or that you have assigned to you (or qa-assigned to you). However, anyone may add a comment to any bug. +</p> <p> - Some people (initially, the initial owners and initial qa-contacts for components in the system) have the ability to give the above two permissions to other people. So, if you really feel that you ought to have one of these permissions, a good person to ask (via private email, please!) is the person who is assigned a relevant bug. +</p> <h2>Other details.</h2> +<p> An initial stab was taken to decide who would be given which of the above permissions. This was determined by some simple heurstics of who was assigned bugs, and who the default owners of bugs were, and a @@ -100,54 +111,58 @@ look at people who seem to have submitted several bugs that appear to have been interesting and valid. Inevitably, we have failed to give someone the permissions they deserve. Please don't take it personally; just bear with us as we shake out the new system. +</p> <p> - - People with one of the two bits above can easily confirm their own bugs, so bugs they submit will actually start out in the NEW state. They can override this when submitting a bug. +</p> <p> - People can ACCEPT or RESOLVE a bug assigned to them, even if they aren't allowed to confirm it. However, the system remembers, and if the bug gets REOPENED or reassigned to someone else, it will revert back to the UNCONFIRMED state. If the bug has ever been confirmed, then REOPENing or reassigning will cause it to go to the NEW or REOPENED state. +</p> <p> - Note that only some products support the UNCONFIRMED state. In other products, all new bugs will automatically start in the NEW state. +</p> <h2>Things still to be done.</h2> +<p> There probably ought to be a way to get a bug back into the UNCONFIRMED state, but there isn't yet. +</p> <p> - If a person has submitted several bugs that get confirmed, then this is probably a person who understands the system well, and deserves the "Can confirm a bug" permission. This kind of person should be detected and promoted automatically. +</p> <p> - There should also be a way to automatically promote people to get the "Can edit all aspects of any bug" permission. +</p> <p> - The "enter a new bug" page needs to be revamped with easy ways for new people to educate themselves on the benefit of searching for a bug like the one they're about to submit and voting on it, rather than adding a new useless duplicate. +</p> <hr> +<p> <!-- hhmts start --> -Last modified: Wed Feb 16 21:04:56 2000 +Last modified: Sun Apr 14 12:55:14 EST 2002 <!-- hhmts end --> +</p> </body> </html> |