summaryrefslogtreecommitdiffstats
path: root/confirmhelp.html
diff options
context:
space:
mode:
Diffstat (limited to 'confirmhelp.html')
-rw-r--r--confirmhelp.html154
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>