confirmhelp.html

<!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>