content/docs/issues_unconfirmedhelp.html.en - openoffice-org - Git at Google

 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
 "http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-strict.dtd">

 <html xmlns="http://www.w3.org/1999/xhtml">
  <head>
 <style type="text/css">
 /* <![CDATA[ */ @import "/branding/css/tigris.css"; /* ]]> */
 </style>
   <script src="/branding/scripts/sc.js" type="text/javascript"></script>
   <link rel="stylesheet" type="text/css" href="/branding/css/print.css" media="print" />

   <title>Understanding the unconfirmed issue state</title>
  </head>

  <body class="docs" onload="self.focus()">
   <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 class="courtesylinks">
     <p><a href="#toc">Top</a> | <a href="/nonav/servlets/HelpTOC">Help index</a></p>
    </div>
   </div>
  </body>
 </html>
	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
	"http://www.w3.org/TR/2000/REC-xhtml1-20000126/DTD/xhtml1-strict.dtd">

	<html xmlns="http://www.w3.org/1999/xhtml">
	<head>
	<style type="text/css">
	/* <![CDATA[ / @import "/branding/css/tigris.css"; / ]]> */
	</style>
	<script src="/branding/scripts/sc.js" type="text/javascript"></script>
	<link rel="stylesheet" type="text/css" href="/branding/css/print.css" media="print" />

	<title>Understanding the unconfirmed issue state</title>
	</head>

	<body class="docs" onload="self.focus()">
	<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 class="courtesylinks">
	<p><a href="#toc">Top</a> \| <a href="/nonav/servlets/HelpTOC">Help index</a></p>
	</div>
	</div>
	</body>
	</html>