diff options
Diffstat (limited to 'confirmhelp.html')
| -rw-r--r-- | confirmhelp.html | 154 |
1 files changed, 154 insertions, 0 deletions
diff --git a/confirmhelp.html b/confirmhelp.html new file mode 100644 index 000000000..5c8e64434 --- /dev/null +++ b/confirmhelp.html @@ -0,0 +1,154 @@ +<HTML><head> + +<!-- + The contents of this file are subject to the Mozilla Public + License Version 1.1 (the "License"); you may not use this file + except in compliance with the License. You may obtain a copy of + the License at http://www.mozilla.org/MPL/ + + Software distributed under the License is distributed on an "AS + IS" basis, WITHOUT WARRANTY OF ANY KIND, either express or + implied. See the License for the specific language governing + rights and limitations under the License. + + The Original Code is the Bugzilla Bug Tracking System. + + The Initial Developer of the Original Code is Netscape Communications + Corporation. Portions created by Netscape are + Copyright (C) 2000 Netscape Communications Corporation. All + Rights Reserved. + + Contributor(s): Terry Weissman <terry@mozilla.org> +--> + +<title>Understanding the UNCONFIRMED state, and other recent changes</title> +</head> + +<body> +<h1>Understanding the UNCONFIRMED state, and other recent changes</h1> + +[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> + +New bugs in some products will now show up in a new state, +UNCONFIRMED. This means that we have nobody has confirmed that the +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> + +The <a href="bug_status.html">page describing bug fields</a> has been +updated to include UNCONFIRMED. +<p> + +There are two basic ways that a bug can become confirmed (and enter +the NEW) state. + +<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 bugs (each user gets a certain + number of bugs); any UNCONFIRMED bug which enough bugs becomes + automatically confirmed, and enters the NEW state. +</ul> + +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. + +<h2>Permissions.</h2> + +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> + +If you have the "Can confirm a bug" permission, then you will be able +to move UNCONFIRMED bugs into the NEW state. + +<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> + +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. + +<h2>Other details.</h2> + +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 +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> + + +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> + +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> + +Note that only some products support the UNCONFIRMED state. In other +products, all new bugs will automatically start in the NEW state. + +<h2>Things still to be done.</h2> + +There probably ought to be a way to get a bug back into the +UNCONFIRMED state, but there isn't yet. + +<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> + +There should also be a way to automatically promote people to get the +"Can edit all aspects of any bug" permission. + +<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. + +<hr> +<!-- hhmts start --> +Last modified: Wed Feb 16 21:04:56 2000 +<!-- hhmts end --> +</body> </html> |