mirror of
https://github.com/mozilla/gecko-dev.git
synced 2024-11-01 22:55:23 +00:00
154 lines
5.4 KiB
HTML
154 lines
5.4 KiB
HTML
<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
|
|
gets enough votes 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>
|