head	1.4;
access;
symbols
	TIGRIS_1_1_0RC2:1.2
	TIGRIS_1_1_0RC1:1.2
	TIGRIS_1_1:1.2.0.4
	TIGRIS_1_0_8:1.2
	TIGRIS_1_0_8RC3:1.2
	TIGRIS_1_0_8RC2:1.2
	TIGRIS_1_0_8RC1:1.2
	TIGRIS_1_0_7:1.2
	TIGRIS_1_0_7RC3:1.2
	TIGRIS_1_0_7RC2:1.2
	TIGRIS_1_0_7RC1:1.2
	TIGRIS_1_0_6:1.2
	TIGRIS_1_0_6RC5:1.2
	TIGRIS_1_0_6RC4:1.2
	TIGRIS_1_0_6RC3:1.2
	TIGRIS_1_0_6RC2:1.2
	TIGRIS_1_0_6RC1:1.2
	TIGRIS_1_0_5:1.2
	TIGRIS_1_0_5RC6:1.2
	TIGRIS_1_0_5RC5:1.2
	TIGRIS_1_0_5RC4:1.2
	TIGRIS_1_0_5RC3:1.2
	TIGRIS_1_0_5RC2:1.2
	TIGRIS_1_0_5RC1:1.2
	TIGRIS_1_0_4:1.2
	TIGRIS_1_0_3:1.2
	TIGRIS_1_0_2:1.2
	TIGRIS_1_0_1:1.2
	TIGRIS_1_0:1.2.0.6
	TIGRIS_1_0_0:1.2
	TIGRIS_1_0_0_RC1:1.2.0.2
	dlr:1.1.1
	TIGRIS_0_9_2_4:1.1
	TIGRIS_0_9_2_3:1.1
	HELM_PEER_PORT_BRANCH:1.1.1.1
	TURBINE_PEER:1.1
	TIGRIS_0_9_2_1:1.1
	TIGRIS_0_9_2:1.1.0.6
	TIGRIS_0_8_4:1.1.0.4
	TIGRIS_0_9_0:1.1.0.2;
locks; strict;
comment	@# @;


1.4
date	2001.06.21.07.07.40;	author jefflove;	state Exp;
branches;
next	1.3;

1.3
date	2001.06.11.03.14.33;	author jefflove;	state Exp;
branches;
next	1.2;

1.2
date	2001.02.11.18.29.47;	author jrobbins;	state Exp;
branches;
next	1.1;

1.1
date	2000.12.30.23.22.01;	author jrobbins;	state Exp;
branches
	1.1.1.1
	1.1.4.1
	1.1.8.1;
next	;

1.1.1.1
date	2001.02.21.00.32.02;	author dlr;	state Exp;
branches;
next	;

1.1.4.1
date	2001.01.16.00.17.44;	author susank;	state Exp;
branches;
next	;

1.1.8.1
date	2001.02.17.18.39.16;	author edk;	state Exp;
branches;
next	;


desc
@@


1.4
log
@html usage revision
@
text
@  <div class="docs" id="issuesunconfirmedhelp">
   <!--
         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 IssueZilla Issue 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>
    -->
<h2>Understanding the UNCONFIRMED issue state</h2>

  <p>[This document is aimed primarily at people who may have used IssueZilla before the <code>UNCONFIRMED</code> state was implemented. It might be helpful for newer users as well.]</p>

  <p>New issues in some products will now show up in a new state, <code>UNCONFIRMED</code>. This means that nobody has confirmed that the issue is real. Very busy developers generally ignore <code>UNCONFIRMED</code> that have been assigned to them, until they have been confirmed in one way or another. (Developers with more time will hopefully glance over their <code>UNCONFIRMED</code> issues regularly.)</p>

  <p>There are two basic ways that an issue can become confirmed (and thus enter the <code>NEW</code>) state.</p>

  <ul>
   <li>A user with the appropriate permissions (see below for more on permissions) decides that the issue is a valid one, and confirms it.</li>

   <li>The issue gathers a certain number of votes. <b>Any</b> valid IssueZilla user may vote for issues (each user gets a certain number of issues); any <code>UNCONFIRMED</code> issue which gets enough votes becomes automatically confirmed, and enters the <code>NEW</code> state.</li>
  </ul>

  <p>That's why it is worthwhile to search the issue database for duplicates of your issue to vote on them <b><i>before</i></b> submitting your own issue. This helps to prevent issue duplication in the database.</p>

  <h3>Permissions and the UNCONFIRMED issue state</h3>

  <p>If you have the "Can confirm an issue" permission, then you will be able to change <code>UNCONFIRMED</code> issues to the <code>NEW</code> state.</p>

  <p>If you not have the "Can confirm an issue" permission, you can still <code>ACCEPT</code> or <code>RESOLVE</code> all issues assigned to you. IssueZilla keeps track of this. If this issue gets <code>REOPENED</code> or reassigned to someone else, it reverts back to the <code>UNCONFIRMED</code> state. If such an issue <i>has</i> been confirmed, then reassigning changes its status to <code>NEW</code> or <code>REOPENED</code>.</p>

  <p>If you have the "Can edit all aspects of any issue" permission, when you submit issues, these start out in the <code>NEW</code> state rather than the <code>UNCONFIRMED</code> state. You can override this feature, however, when you want to submit an issue as <code>UNCONFIRMED</code>.</p>
 </div>



@


1.3
log
@extensive markup rework - first pass toward house xhtmlification
@
text
@d1 2
a2 10
<!DOCTYPE html PUBLIC "-//CollabNet//DTD XHTML 1.0 Transitional//EN"
"http://collabnet.com/dtds/collabnet_transitional_10.dtd">
<html>
 <head>
  <title>Understanding the UNCONFIRMED Issue State</title>
 </head>

 <body>
  <!-- style/format note: Headings/fonts should be updated to conform to scast style -->
  <!--
a21 2

  <div class="docs" id="docid">
d46 1
a46 2
</body>
</html>
@


1.2
log
@added <title> tags to all files
@
text
@d1 57
a57 2
<HTML>
<HEAD>
a58 1
<TITLE>Understanding the UNCONFIRMED Issue State</TITLE>
a59 113
</HEAD>
<BODY>
<!-- style/format note: Headings/fonts should be updated to conform to scast style -->

<!--
     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 IssueZilla Issue 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>
-->
<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%">
  <TR>
    <TD class="Header" nowrap>Understanding the UNCONFIRMED issue state</TD>  
  </TR>
</TABLE>
<TABLE BORDER="0" CELLSPACING="2" CELLPADDING="2" BORDER="0" width="100%">
  <TR>
    <TD class="PlainText" VALIGN="top">

<P>[This document is aimed primarily at people who may have used
IssueZilla before the <span class="TypewriterBold">UNCONFIRMED</span>
state was implemented. It might be helpful for newer users as well.]

<P>

New issues in some products will now show up in a new state, <span
class="TypewriterBold">UNCONFIRMED</span>.  This means that nobody has
confirmed that the issue is real. Very busy developers generally
ignore <span class="TypewriterBold">UNCONFIRMED</span> that have been
assigned to them, until they have been confirmed in one way or
another.  (Developers with more time will hopefully glance over their
<span class="TypewriterBold">UNCONFIRMED</span> issues regularly.)

<P>

There are two basic ways that an issue can become confirmed (and thus
enter the <span class="TypewriterBold">NEW</span>) state.

<UL>

  <LI> A user with the appropriate permissions (see below for more on
       permissions) decides that the issue is a valid one, and confirms
       it.
<P>

  <LI> The issue gathers a certain number of votes. <B>Any</B> valid
  IssueZilla user may vote for issues (each user gets a certain number
  of issues); any <span class="TypewriterBold">UNCONFIRMED</span>
  issue which gets enough votes becomes automatically confirmed, and
  enters the <span class="TypewriterBold">NEW</span> state.

</UL>

That's why it is worthwhile to search the issue database for
duplicates of your issue to vote on them <B><I>before</I></B>
submitting your own issue. This helps to prevent issue duplication in
the database.

<P><span class="InputHeader">Permissions and the UNCONFIRMED issue state</span>

<P>
If you have the "Can confirm an issue" permission, then you will be
able to change <span class="TypewriterBold">UNCONFIRMED</span> issues
to the <span class="TypewriterBold">NEW</span> state.

<P>
If you not have the "Can confirm an issue" permission, you can still
<span class="TypewriterBold">ACCEPT</span> or <span
class="TypewriterBold">RESOLVE</span> all issues assigned to
you. IssueZilla keeps track of this. If this issue gets <span
class="TypewriterBold">REOPENED</span> or reassigned to someone else,
it reverts back to the <span class="TypewriterBold">UNCONFIRMED</span>
state. If such an issue <i>has</i> been confirmed, then reassigning
changes its status to <span class="TypewriterBold">NEW</span> or <span
class="TypewriterBold">REOPENED</span>.

<P>
If you have the "Can edit all aspects of any issue" permission, when
you submit issues, these start out in the <span
class="TypewriterBold">NEW</span> state rather than the <span
class="TypewriterBold">UNCONFIRMED</span> state. You can override this
feature, however, when you want to submit an issue as <span
class="TypewriterBold">UNCONFIRMED</span>.


    </TD>
  </TR>
</TABLE>









</BODY>
</HTML>
@


1.1
log
@moved core documentation into helm, fewer overrides need to be in instances now
@
text
@d1 7
d117 2
@


1.1.1.1
log
@Replacing the HEAD with the HELM_PEER_PORT_BRANCH.
@
text
@a0 7
<HTML>
<HEAD>

<TITLE>Understanding the UNCONFIRMED Issue State</TITLE>

</HEAD>
<BODY>
a109 2
</BODY>
</HTML>
@


1.1.8.1
log
@porting changes from the head to the branch
@
text
@a0 7
<HTML>
<HEAD>

<TITLE>Understanding the UNCONFIRMED Issue State</TITLE>

</HEAD>
<BODY>
a109 2
</BODY>
</HTML>
@


1.1.4.1
log
@adding the generic, default docs into this branch, bc they are in the head and nec for instantiations using stable branches
@
text
@@

