From b771be6f8820b5a5436c3cb4b188f4f9d9594810 Mon Sep 17 00:00:00 2001 From: "gerv%gerv.net" <> Date: Sat, 28 Sep 2002 05:03:54 +0000 Subject: Bug 170213 - CVS remove old and obsolete HTML files. "Patch" by gerv; a=myk. --- confirmhelp.html | 168 ------------------------------------------------------- 1 file changed, 168 deletions(-) delete mode 100644 confirmhelp.html (limited to 'confirmhelp.html') diff --git a/confirmhelp.html b/confirmhelp.html deleted file mode 100644 index 20ccfd402..000000000 --- a/confirmhelp.html +++ /dev/null @@ -1,168 +0,0 @@ - - - - - - -Understanding the UNCONFIRMED state, and other recent changes - - - -

Understanding the UNCONFIRMED state, and other recent changes

- -

-[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.] -

- -

- -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.) -

- -

-The page describing bug fields has been -updated to include UNCONFIRMED. -

- -

-There are two basic ways that a bug can become confirmed (and enter -the NEW) state. -

- - - -

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

- -

Permissions.

- -

-Users now have a certain set of permissions. To see your permissions, -check out the -user preferences page. -

- -

-If you have the "Can confirm a bug" permission, then you will be able -to move UNCONFIRMED bugs into the NEW state. -

- -

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

- -

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

- -

Other details.

- -

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

- -

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

- -

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

- -

-Note that only some products support the UNCONFIRMED state. In other -products, all new bugs will automatically start in the NEW state. -

- -

Things still to be done.

- -

-There probably ought to be a way to get a bug back into the -UNCONFIRMED state, but there isn't yet. -

- -

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

- -

-There should also be a way to automatically promote people to get the -"Can edit all aspects of any bug" permission. -

- -

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

- -
-

- -Last modified: Sun Apr 14 12:55:14 EST 2002 - -

- -- cgit v1.2.3-24-g4f1b