diff options
| author | terry%mozilla.org <> | 2000-02-17 14:15:20 +0100 |
|---|---|---|
| committer | terry%mozilla.org <> | 2000-02-17 14:15:20 +0100 |
| commit | e9a32920f47ce268e3835b12abccc9fb2e1dd8c6 (patch) | |
| tree | 8f1154745b807d4dee480e7b5c22d3ccb4b27f07 /confirmhelp.html | |
| parent | 3c0ea11d42d7942f36e1704afefc55655811db5d (diff) | |
| download | bugzilla-e9a32920f47ce268e3835b12abccc9fb2e1dd8c6.tar.gz bugzilla-e9a32920f47ce268e3835b12abccc9fb2e1dd8c6.tar.xz | |
Major spankage. Added a new state, UNCONFIRMED. Added new groups,
"editbugs" and "canconfirm". People without these states are now much
more limited in what they can do.
For backwards compatability, by default all users will have the
editbugs and canconfirm bits on them. Installing this changes as is
should only have one major visible effect -- an UNCONFIRMED state
will appear in the query page. But no bugs will become in that state,
until you tweak some of the new voting-related parameters you'll find
when editing products.
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> |