summaryrefslogtreecommitdiffstats
path: root/confirmhelp.html
diff options
context:
space:
mode:
Diffstat (limited to 'confirmhelp.html')
-rw-r--r--confirmhelp.html168
1 files changed, 0 insertions, 168 deletions
diff --git a/confirmhelp.html b/confirmhelp.html
deleted file mode 100644
index 20ccfd402..000000000
--- a/confirmhelp.html
+++ /dev/null
@@ -1,168 +0,0 @@
-<!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
- 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>
--->
-
-<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>
-
-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>
-
-<p>
-The <a href="bug_status.html">page describing bug fields</a> has been
-updated to include UNCONFIRMED.
-</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>
- <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.</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
-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: Sun Apr 14 12:55:14 EST 2002
-<!-- hhmts end -->
-</p>
-</body> </html>