head	1.7;
access;
symbols
	TIGRIS_1_1_0RC2:1.4.6.1
	TIGRIS_1_1_0RC1:1.4.6.1
	TIGRIS_1_1:1.4.6.1.0.2
	TIGRIS_1_0_8:1.4.6.1
	TIGRIS_1_0_8RC3:1.4.6.1
	TIGRIS_1_0_8RC2:1.4.6.1
	TIGRIS_1_0_8RC1:1.4.6.1
	TIGRIS_1_0_7:1.4.6.1
	TIGRIS_1_0_7RC3:1.4.6.1
	TIGRIS_1_0_7RC2:1.4.6.1
	TIGRIS_1_0_7RC1:1.4.6.1
	TIGRIS_1_0_6:1.4.6.1
	TIGRIS_1_0_6RC5:1.4.6.1
	TIGRIS_1_0_6RC4:1.4.6.1
	TIGRIS_1_0_6RC3:1.4
	TIGRIS_1_0_6RC2:1.4
	TIGRIS_1_0_6RC1:1.4
	TIGRIS_1_0_5:1.4
	TIGRIS_1_0_5RC6:1.4
	TIGRIS_1_0_5RC5:1.4
	TIGRIS_1_0_5RC4:1.4
	TIGRIS_1_0_5RC3:1.4
	TIGRIS_1_0_5RC2:1.4
	TIGRIS_1_0_5RC1:1.4
	TIGRIS_1_0_4:1.4
	TIGRIS_1_0_3:1.4
	TIGRIS_1_0_2:1.4
	TIGRIS_1_0_1:1.4
	TIGRIS_1_0:1.4.0.6
	TIGRIS_1_0_0:1.4
	TIGRIS_1_0_0_RC1:1.4.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.2
	TIGRIS_0_9_2_1:1.2
	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.7
date	2001.06.21.07.07.40;	author jefflove;	state Exp;
branches;
next	1.6;

1.6
date	2001.06.11.03.14.33;	author jefflove;	state Exp;
branches;
next	1.5;

1.5
date	2001.06.04.20.33.21;	author lori;	state Exp;
branches;
next	1.4;

1.4
date	2001.03.16.23.50.03;	author lori;	state Exp;
branches
	1.4.6.1;
next	1.3;

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

1.2
date	2001.01.23.00.06.03;	author kmaples;	state Exp;
branches
	1.2.2.1;
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;
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.2.2.1
date	2001.02.17.18.39.16;	author edk;	state Exp;
branches;
next	;

1.4.6.1
date	2001.06.13.00.43.15;	author lori;	state Exp;
branches;
next	;


desc
@@


1.7
log
@html usage revision
@
text
@  <div class="docs" id="issuelifecycle">
   <!--
          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) 1998 Netscape Communications Corporation. All
          Rights Reserved.
         
          Contributor(s): 
          Contributor(s): Terry Weissman <terry@@mozilla.org>
     -->

   <h2>An Issue's Life Cycle</h2>

   <div class="toc">
    <h3>Additional resources about issues: Index</h3>

    <ul>
     <li>
      <a href="ProjectIssues.html">Project Issues help</a> 

      <ul>
       <li><strong>You are here:</strong> The issue life cycle</li>

       <li><a href="issuewritinghelp.html">Issue writing guidelines</a></li>

       <li><a href="issuezilla_tipsandtricks.html">IssueZilla tips and tricks</a></li>

       <li><a href="contributing_patches.html">Contributing patches</a></li>
      </ul>
     </li>
    </ul>
   </div>

   <div class="courtesylinks">
    <p><a href="/servlets/HelpTOC">Back to main Help index</a></p>
   </div>

   <table border="0" cellspacing="0" cellpadding="2">
    <tr>
     <th><a id="lifecycle_table" name="lifecycle_table">Status</a> </th>

     <th>Resolution</th>
    </tr>

    <tr class="a">
     <td>The <b>status</b> field indicates the general health of an issue. Only certain status transitions are allowed.</td>

     <td>The <b>resolution</b> field indicates what happened to this issue.</td>
    </tr>

    <tr>
     <td>
      <dl>
       <dt><a href="issues_unconfirmedhelp.html">UNCONFIRMED</a></dt>

       <dd>This issue has recently been added to the database. Nobody has validated that this issue is true. Users who have the "canconfirm" permission set may confirm this issue, changing its state to <b>NEW</b>. Or, it may be directly resolved and marked <b>RESOLVED</b>.</dd>

       <dt>NEW</dt>

       <dd>This issue has recently been added to the assignee's list of issues and must be processed. Issues in this state may be accepted, and become <b>STARTED</b>, passed on to someone else, and remain <b>NEW</b>, or resolved and marked <b>RESOLVED</b>.</dd>

       <dt>STARTED</dt>

       <dd>This issue is not yet resolved, but is assigned to the proper person. From here issues can be given to another person and become <b>NEW</b>, or resolved and become <b>RESOLVED</b>.</dd>

       <dt>REOPENED</dt>

       <dd>This issue was once resolved, but the resolution was deemed incorrect. For example, a <b>WORKSFORME</b> issue is <b>REOPENED</b> when more information shows up and the issue is now reproducible. From here issues are either marked <b>STARTED</b> or <b>RESOLVED</b>.</dd>
      </dl>
     </td>

     <td>
      <p>No resolution yet. All issues which are in one of these "open" states have the resolution set to blank. All other issues will be marked with one of the resolutions below.</p>
     </td>
    </tr>

    <tr>
     <td>
      <dl>
       <dt>RESOLVED</dt>

       <dd>A resolution has been taken, and it is awaiting verification by QA. From here issues are either re-opened and become <b>REOPENED</b>, are marked <b>VERIFIED</b>, or are closed for good and marked <b>CLOSED</b>.</dd>

       <dt>VERIFIED</dt>

       <dd>QA has looked at the issue and the resolution and agrees that the appropriate resolution has been taken. Issues remain in this state until the product they were reported against is actually released, at which point they become <b>CLOSED</b>.</dd>

       <dt>CLOSED</dt>

       <dd>The issue is considered dead, the resolution is correct. Any zombie issues who choose to walk the earth again must do so by becoming <b>REOPENED</b>.</dd>
      </dl>
     </td>

     <td>
      <dl>
       <dt>FIXED</dt>

       <dd>A fix for this issue is checked into the source code repository and tested.</dd>

       <dt>INVALID</dt>

       <dd>The problem described is not an issue</dd>

       <dt>WONTFIX</dt>

       <dd>The problem described is an issue which will never be fixed.</dd>

       <dt>LATER</dt>

       <dd>The problem described is an issue which will not be fixed in this version of the product.</dd>

       <dt>REMIND</dt>

       <dd>The problem described is an issue which will probably not be fixed in this version of the product, but might still be.</dd>

       <dt>DUPLICATE</dt>

       <dd>The problem is a duplicate of an existing issue. Marking an issue duplicate requires the issue number of the duplicating issue and will at least put that issue number in the description field.</dd>

       <dt>WORKSFORME</dt>

       <dd>All attempts at reproducing this issue were futile, reading the code produces no clues as to why this behavior would occur. If more information appears later, please re-assign the issue, for now, file it.</dd>
      </dl>
     </td>
    </tr>
   </table>

   <h3><a id="issuesequence" name="issuesequence">More about the sequence of an issue's status</a></h3>

   <p>What happens to an issue when it is first reported depends on who reported it. By default, issues reported (that is, entered) into IssueZilla are assigned a status of <code>UNCONFIRMED</code>. This means that a QA (Quality Assurance) person -- or whoever has the appropriate permissions on your project -- needs to confirm that this issue is legitimate before changing its status to <code>NEW</code>. By sending mail to <!-- is
              this the right alias?
              -->issues-subscribe@@&lt;projectname&gt;.domain.com, you can be notified of all changes to an issue. You then use issue tracking to view and further "workflow" the issue.</p>

   <p>If you are a project member who is a developer/user/tester, you can create <code>NEW</code> issues and assign them to other developers. When an issue's status becomes <code>NEW</code>, the developer assigned the issue either accepts it or reassigns it to someone else. If the issue remains new and inactive for more than a week, IssueZilla nags the issue's owner with email until action is taken. Whenever a issue is reassigned or has its component changed, its status is set back to <code>NEW</code>. The <code>NEW</code> status means that the issue is newly added to a particular developer's plate, not that the issue is newly reported. Think of <code>NEW</code> as an important e-mail you need to answer, except you respond through IssueZilla, and you can use this tool to track the issue's progress more efficiently than e-mail.</p>

   <p>Some project members with additional permissions have the ability to change all the fields of a issue. (Default permissions only allow limited fields to be changed. (<a href="/docs/ProjectIssues.html#permissions">Read more about IssueZilla permissions</a>). Whenever you change a field in a issue it's a good idea to add additional comments to explain what you are doing and why. Make a note in the comments field whenever you:</p>

   <ul>
    <li>change the component</li>

    <li>reassign the issue</li>

    <li>create an attachment</li>

    <li>add a dependency, or</li>

    <li>add someone to the CC list.</li>
   </ul>

   <p>Whenever someone else makes a change to an issue or adds a comment, they are added to the CC list and the owner, reporter, and CC list receive an email announcing changes to the issue. This email reports the change using a "diff" format, marking which lines have changed and including any new comments.</p>

   <h3><a id="verifyissues" name="verifyissues">Verifying issues</a></h3>

   <p>When issues are marked resolved, project/component owners look at these to make sure the appropriate action has been taken. If they agree, the issue is marked <code>VERIFIED</code>. Issues remain in this state until the product or version is released, then the issue is marked <code>CLOSED</code>. Issues may come back to life by becoming <code>REOPENED</code>.</p>

   <p>Be careful about changing the status of someone else's issues. Instead of making the change yourself, it's usually best to make a note of your proposed change as a comment <i>first</i> and to let the issue's owner review this and make the change themselves. For example, if you think one issue is a duplicate of another, make a note of it in the "Additional Comments" section of the issue.</p>

   <p>If you make a lot of useful comments to others' issues, you gain their trust in your judgement and you may be given permissions to go ahead and make the changes yourself. Unless and until this happens, exercise discretion by using the "Additional Comments" section.</p>

   <div class="courtesylinks">
    <p><a href="ProjectIssues.html">Back to Project Issues help</a><br />
    <a href="/servlets/HelpTOC">Back to main Help index</a></p>
   </div>
  </div>
 


@


1.6
log
@extensive markup rework - first pass toward house xhtmlification
@
text
@d1 22
a22 51
<!DOCTYPE html PUBLIC "-//CollabNet//DTD XHTML 1.0 Transitional//EN"
"http://collabnet.com/dtds/collabnet_transitional_10.dtd">
<html>
 <head>
  <title>Issue Life Cycle</title>
<style type="text/css">
 dt.c2 {font-weight: bold}
 div.c1 {margin-left: 2em}
</style>
 </head>

 <body>
  <!--
       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) 1998 Netscape Communications Corporation. All
       Rights Reserved.
      
       Contributor(s): 
       Contributor(s): Terry Weissman <terry@@mozilla.org>
  -->
  <div class="docs" id="docid">
<h2>An Issue's Life Cycle</h2> 

  <p><strong>Additional resources about issues: Index</strong></p>

  <div>
   <dl>
    <dt><a href="ProjectIssues.html">Project Issues help</a></dt>

    <dd>
     <strong>You are here: <a href="#lifecycle_table">The issue life cycle</a></strong>

     <ul>
      <li><strong><a href="#issuesequence">More about the sequence of an issue's status</a></strong></li>

      <li><strong><a href="#verifyissues">Verifying issues</a></strong></li>
     </ul>
    </dd>
d24 1
a24 1
    <dd><a href="issuewritinghelp.html">Issue writing guidelines</a></dd>
d26 2
a27 1
    <dd><a href="issuezilla_tipsandtricks.html">IssueZilla tips and tricks</a></dd>
d29 3
a31 1
    <dd><a href="contributing_patches.html">Contributing patches</a></dd>
d33 12
a44 3
    <dt><a href="/servlets/HelpTOC">Back to main Help index</a></dt>
   </dl>
  </div>
d46 3
d50 3
a52 5
  <table border="1" cellspacing="2" cellpadding="2" border="0" width="100%">
   <tr>
    <td valign="top">
     <h3><a id="lifecycle_table" name="lifecycle_table">STATUS</a></h3>
    </td>
d54 2
a55 4
    <td valign="top">
     <h3>RESOLUTION</h3>
    </td>
   </tr>
d57 2
a58 2
   <tr valign="top">
    <td>The <b>status</b> field indicates the general health of an issue. Only certain status transitions are allowed.</td>
d60 2
a61 2
    <td valign="top">The <b>resolution</b> field indicates what happened to this issue.</td>
   </tr>
d63 4
a66 4
   <tr valign="top">
    <td>
     <dl>
      <dt class="c2"><a href="issues_unconfirmedhelp.html">UNCONFIRMED</a></dt>
d68 1
a68 1
      <dd>This issue has recently been added to the database. Nobody has validated that this issue is true. Users who have the "canconfirm" permission set may confirm this issue, changing its state to <b>NEW</b>. Or, it may be directly resolved and marked <b>RESOLVED</b>.</dd>
d70 1
a70 1
      <dt class="c2">NEW</dt>
d72 1
a72 1
      <dd>This issue has recently been added to the assignee's list of issues and must be processed. Issues in this state may be accepted, and become <b>STARTED</b>, passed on to someone else, and remain <b>NEW</b>, or resolved and marked <b>RESOLVED</b>.</dd>
d74 1
a74 1
      <dt class="c2">STARTED</dt>
d76 1
a76 1
      <dd>This issue is not yet resolved, but is assigned to the proper person. From here issues can be given to another person and become <b>NEW</b>, or resolved and become <b>RESOLVED</b>.</dd>
d78 1
a78 1
      <dt class="c2">REOPENED</dt>
d80 3
a82 3
      <dd>This issue was once resolved, but the resolution was deemed incorrect. For example, a <b>WORKSFORME</b> issue is <b>REOPENED</b> when more information shows up and the issue is now reproducible. From here issues are either marked <b>STARTED</b> or <b>RESOLVED</b>.</dd>
     </dl>
    </td>
d84 4
a87 6
    <td>
     <dl>
      <dd>No resolution yet. All issues which are in one of these "open" states have the resolution set to blank. All other issues will be marked with one of the resolutions below.</dd>
     </dl>
    </td>
   </tr>
d89 4
a92 4
   <tr valign="top">
    <td>
     <dl>
      <dt class="c2">RESOLVED</dt>
d94 1
a94 1
      <dd>A resolution has been taken, and it is awaiting verification by QA. From here issues are either re-opened and become <b>REOPENED</b>, are marked <b>VERIFIED</b>, or are closed for good and marked <b>CLOSED</b>.</dd>
d96 1
a96 1
      <dt class="c2">VERIFIED</dt>
d98 1
a98 1
      <dd>QA has looked at the issue and the resolution and agrees that the appropriate resolution has been taken. Issues remain in this state until the product they were reported against is actually released, at which point they become <b>CLOSED</b>.</dd>
d100 1
a100 1
      <dt class="c2">CLOSED</dt>
d102 3
a104 3
      <dd>The issue is considered dead, the resolution is correct. Any zombie issues who choose to walk the earth again must do so by becoming <b>REOPENED</b>.</dd>
     </dl>
    </td>
d106 3
a108 3
    <td>
     <dl>
      <dt class="c2">FIXED</dt>
d110 1
a110 1
      <dd>A fix for this issue is checked into the source code repository and tested.</dd>
d112 1
a112 1
      <dt class="c2">INVALID</dt>
d114 1
a114 1
      <dd>The problem described is not an issue</dd>
d116 1
a116 1
      <dt class="c2">WONTFIX</dt>
d118 1
a118 1
      <dd>The problem described is an issue which will never be fixed.</dd>
d120 1
a120 1
      <dt class="c2">LATER</dt>
d122 1
a122 1
      <dd>The problem described is an issue which will not be fixed in this version of the product.</dd>
d124 1
a124 1
      <dt class="c2">REMIND</dt>
d126 1
a126 1
      <dd>The problem described is an issue which will probably not be fixed in this version of the product, but might still be.</dd>
d128 1
a128 1
      <dt class="c2">DUPLICATE</dt>
d130 1
a130 1
      <dd>The problem is a duplicate of an existing issue. Marking an issue duplicate requires the issue number of the duplicating issue and will at least put that issue number in the description field.</dd>
d132 1
a132 1
      <dt class="c2">WORKSFORME</dt>
d134 5
a138 2
      <dd>All attempts at reproducing this issue were futile, reading the code produces no clues as to why this behavior would occur. If more information appears later, please re-assign the issue, for now, file it.</dd>
     </dl>
d140 1
a140 4
     
    </td>
   </tr>
  </table>
d142 3
a144 1
<h3><a id="issuesequence" name="issuesequence">More about the sequence of an issue's status</a></h3>
d146 1
a146 3
     <p>What happens to an issue when it is first reported depends on who reported it. By default, issues reported (that is, entered) into IssueZilla are assigned a status of <code>UNCONFIRMED</code>. This means that a QA (Quality Assurance) person -- or whoever has the appropriate permissions on your project -- needs to confirm that this issue is legitimate before changing its status to <code>NEW</code>. By sending mail to <!-- is
           this the right alias?
           -->issues-subscribe@@&lt;projectname&gt;.domain.com, you can be notified of all changes to an issue. You then use issue tracking to view and further "workflow" the issue.</p>
d148 1
a148 1
     <p>If you are a project member who is a developer/user/tester, you can create <code>NEW</code> issues and assign them to other developers. When an issue's status becomes <code>NEW</code>, the developer assigned the issue either accepts it or reassigns it to someone else. If the issue remains new and inactive for more than a week, IssueZilla nags the issue's owner with email until action is taken. Whenever a issue is reassigned or has its component changed, its status is set back to <code>NEW</code>. The <code>NEW</code> status means that the issue is newly added to a particular developer's plate, not that the issue is newly reported. Think of <code>NEW</code> as an important e-mail you need to answer, except you respond through IssueZilla, and you can use this tool to track the issue's progress more efficiently than e-mail.</p>
d150 2
a151 1
     <p>Some project members with additional permissions have the ability to change all the fields of a issue. (Default permissions only allow limited fields to be changed. (<a href="/docs/ProjectIssues.html#permissions">Read more about IssueZilla permissions</a>). Whenever you change a field in a issue it's a good idea to add additional comments to explain what you are doing and why. Make a note in the comments field whenever you:</p>
d153 1
a153 2
     <ul>
      <li>change the component</li>
d155 1
a155 1
      <li>reassign the issue</li>
d157 1
a157 1
      <li>create an attachment</li>
d159 2
a160 1
      <li>add a dependency, or</li>
d162 1
a162 2
      <li>add someone to the CC list.</li>
     </ul>
d164 1
a164 1
     <p>Whenever someone else makes a change to an issue or adds a comment, they are added to the CC list and the owner, reporter, and CC list receive an email announcing changes to the issue. This email reports the change using a "diff" format, marking which lines have changed and including any new comments.</p>
d166 1
a166 1
     <h3><a id="verifyissues" name="verifyissues">Verifying issues</a></h3>
d168 1
a168 1
       <p>When issues are marked resolved, project/component owners look at these to make sure the appropriate action has been taken. If they agree, the issue is marked <code>VERIFIED</code>. Issues remain in this state until the product or version is released, then the issue is marked <code>CLOSED</code>. Issues may come back to life by becoming <code>REOPENED</code>.</p>
d170 1
a170 1
       <p>Be careful about changing the status of someone else's issues. Instead of making the change yourself, it's usually best to make a note of your proposed change as a comment <i>first</i> and to let the issue's owner review this and make the change themselves. For example, if you think one issue is a duplicate of another, make a note of it in the "Additional Comments" section of the issue.</p>
d172 6
a177 9
       <p>If you make a lot of useful comments to others' issues, you gain their trust in your judgement and you may be given permissions to go ahead and make the changes yourself. Unless and until this happens, exercise discretion by using the "Additional Comments" section.</p>
   
  
  
  <div class="courtesylinks"><a href="ProjectIssues.html">Back to Project Issues help</a><br />
<a href="/servlets/HelpTOC">Back to main Help index</a></div>
 </div>
</body>
</html>
@


1.5
log
@fixed broken link reference IZ permissions info; issue 4369
@
text
@d1 2
d4 58
a61 1
<head>
a62 1
<title>Issue Life Cycle</title>
d64 71
a134 2
</head>
<body>
d136 20
a155 38
<!--
     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) 1998 Netscape Communications Corporation. All
     Rights Reserved.
    
     Contributor(s): 
     Contributor(s): Terry Weissman <terry@@mozilla.org>
-->
 <span class="Header" nowrap>An Issue's Life Cycle</span>
<p>  
 <span class="PlainText"><strong>Additional resources about issues: Index</strong>
<ul>
	<dl>
	<dt><a href="ProjectIssues.html">Project Issues help</a>
		<dd><strong>You are here: <a href="#lifecycle_table">The issue life cycle</a>
			 <ul>
		       <li><a href="#issuesequence">More about the sequence of an issue's status</a>
		       <li><a href="#verifyissues">Verifying issues</a>
		      </ul></strong>
		<dd><a href="issuewritinghelp.html">Issue writing guidelines</a>
		<dd><a href="issuezilla_tipsandtricks.html"> IssueZilla tips and tricks</a> 
		<dd><a href="contributing_patches.html">Contributing patches</a>
	<dt><a href="/servlets/HelpTOC">Back to main Help index</a>
	</dl>
</ul>
a156 1
 
d158 41
a198 181
 
<a name="lifecycle_table"></a><table border="1" cellspacing="2" cellpadding="2" border="0" width="100%">
   <tr>
    <td valign="top"><h3>STATUS</h3></td> 
    <td valign="top"><h3>RESOLUTION</h3></td>
  </tr>
  <tr valign=top>
    <td class="PlainText">The <b>status</b> field indicates the general health of an issue. Only certain status transitions are allowed.</td>
    <td class="PlainText" valign="top">The <b>resolution</b> field indicates what happened to this issue.</td>
  </tr>
  <tr valign=top>
    <td class="PlainText">
      <dl>
        <dt><b><a href="issues_unconfirmedhelp.html">UNCONFIRMED</a></b> 
        <dd> This issue has recently been added to the database.  Nobody has
     validated that this issue is true.  Users who have the "canconfirm"
     permission set may confirm this issue, changing its state to <b>NEW</b>.
     Or, it may be directly resolved and marked <b>RESOLVED</b>.
        <dt><b>NEW</b> 
        <dd> This issue has recently been added to the assignee's list of issues
     and must be processed. Issues in this state may be accepted, and
     become <b>STARTED</b>, passed on to someone else, and remain
     <b>NEW</b>, or resolved and marked <b>RESOLVED</b>.
        <dt><b>STARTED</b> 
        <dd> This issue is not yet resolved, but is assigned to the proper
     person. From here issues can be given to another person and become
     <b>NEW</b>, or resolved and become <b>RESOLVED</b>.
        <dt><b>REOPENED</b>
        <dd>This issue was once resolved, but the resolution was deemed
     incorrect.  For example, a <b>WORKSFORME</b> issue is
     <b>REOPENED</b> when more information shows up and the issue is now
     reproducible.  From here issues are either marked <b>STARTED</b>
     or <b>RESOLVED</b>.
      </dl>
    </td>
    <td class="PlainText">
      <dl>
        <dd> No resolution yet. All issues which are in one of these "open" states have the resolution set to blank. All other issues will be marked with one of the resolutions below.
      </dl>
    </td>
  </tr>
  <tr valign=top>
    <td class="PlainText">
      <dl>
        <dt><b>RESOLVED</b> 
        <dd> A resolution has been taken, and it is awaiting verification by
     QA. From here issues are either re-opened and become
     <b>REOPENED</b>, are marked <b>VERIFIED</b>, or are closed for good
     and marked <b>CLOSED</b>.
        <dt><b>VERIFIED</b>
        <dd> QA has looked at the issue and the resolution and agrees that the
     appropriate resolution has been taken.  Issues remain in this state
     until the product they were reported against is actually released, at
     which point they become <b>CLOSED</b>.
        <dt><b>CLOSED</b> 
        <dd> The issue is considered dead, the resolution is correct. Any zombie
     issues who choose to walk the earth again must do so by becoming
     <b>REOPENED</b>.
      </dl>
    </td>
    <td class="PlainText">  
      <dl>
        <dt><b>FIXED</b>
        <dd> A fix for this issue is checked into the source code repository and tested.
        <dt><b>INVALID</b>
        <dd> The problem described is not an issue 
        <dt><b>WONTFIX</b>
        <dd> The problem described is an issue which will never be fixed.
        <dt><b>LATER</b>
        <dd> The problem described is an issue which will not be fixed in this
     version of the product.
        <dt><b>REMIND</b>
        <dd> The problem described is an issue which will probably not be fixed in this
     version of the product, but might still be.
        <dt><b>DUPLICATE</b>
        <dd> The problem is a duplicate of an existing issue. Marking an issue
     duplicate requires the issue number of the duplicating issue and will at
     least put that issue number in the description field.
        <dt><b>WORKSFORME</b>
        <dd> All attempts at reproducing this issue were futile, reading the
     code produces no clues as to why this behavior would occur. If
     more information appears later, please re-assign the issue, for
     now, file it.
      </dl>
      <p>
    </td>
  </tr>
</table>

<table border="0" cellspacing="2" cellpadding="2" border="0" width="100%">
  <tr>
    <td class="PlainText" valign="top">
      <p><span class="InputHeader"><a name="issuesequence">More about the sequence of an issue's status</a></span>

      <p>What happens to an issue when it is first reported depends on
      who reported it. By default, issues reported (that is, entered)
      into IssueZilla are assigned a status of <span
      class="TypewriterBold">UNCONFIRMED</span>. This means that a QA
      (Quality Assurance) person -- or whoever has the appropriate
      permissions on your project -- needs to confirm that this issue
      is legitimate before changing its status to <span
      class="TypewriterBold">NEW</span>. By sending mail to <!-- is
      this the right alias?
      -->issues-subscribe@@&lt;projectname&gt;.domain.com, you can be
      notified of all changes to an issue. You then use issue tracking
      to view and further &quot;workflow&quot; the issue.

      <p>If you are a project member who is a developer/user/tester,
      you can create <span class="TypewriterBold">NEW</span> issues
      and assign them to other developers. When an issue's status
      becomes <span class="TypewriterBold">NEW</span>, the developer
      assigned the issue either accepts it or reassigns it to someone
      else. If the issue remains new and inactive for more than a
      week, IssueZilla nags the issue's owner with email until action
      is taken. Whenever a issue is reassigned or has its component
      changed, its status is set back to <span
      class="TypewriterBold">NEW</span>. The <span
      class="TypewriterBold">NEW</span> status means that the issue is
      newly added to a particular developer's plate, not that the
      issue is newly reported. Think of <span
      class="TypewriterBold">NEW</span> as an important e-mail you
      need to answer, except you respond through IssueZilla, and you
      can use this tool to track the issue's progress more efficiently
      than e-mail.

      <p>Some project members with additional permissions have the
      ability to change all the fields of a issue. (Default
      permissions only allow limited fields to be changed. (<a
      href="/docs/ProjectIssues.html#permissions">Read
      more about IssueZilla permissions</a>). Whenever you change a
      field in a issue it's a good idea to add additional comments to
      explain what you are doing and why. Make a note in the comments
      field whenever you:
      <ul>
        <li>change the component
        <li>reassign the issue
        <li>create an attachment
        <li>add a dependency, or
        <li>add someone to the CC list.
      </ul>

      <p>Whenever someone else makes a change to an issue or adds a
      comment, they are added to the CC list and the owner, reporter,
      and CC list receive an email announcing changes to the
      issue. This email reports the change using a "diff" format,
      marking which lines have changed and including any new comments.
      <dl>

      <p>
<span class="InputHeader"><a name="verifyissues"></a>Verifying issues</span>

      <p>When issues are marked resolved, project/component owners
      look at these to make sure the appropriate action has been
      taken. If they agree, the issue is marked <span
      class="TypewriterBold">VERIFIED</span>. Issues remain in this
      state until the product or version is released, then the issue
      is marked <span class="TypewriterBold">CLOSED</span>. Issues may
      come back to life by becoming 
      <span class="TypewriterBold">REOPENED</span>.  <p>Be careful about
      changing the status of someone else's issues. Instead of making
      the change yourself, it's usually best to make a note of your
      proposed change as a comment <i>first</i> and to let the issue's
      owner review this and make the change themselves. For example,
      if you think one issue is a duplicate of another, make a note of
      it in the "Additional Comments" section of the issue.

      <p>If you make a lot of useful comments to others' issues, you
      gain their trust in your judgement and you may be given
      permissions to go ahead and make the changes yourself. Unless
      and until this happens, exercise discretion by using the
      "Additional Comments" section.

    </td>
  </tr>
</table>

 <hr noshade size=1>
<span class="PlainText">
<a href="ProjectIssues.html">Back to Project Issues help</a><br>
<a href="/servlets/HelpTOC">Back to main Help index</a>
</span>
d201 2
@


1.4
log
@added index
@
text
@d178 1
a178 1
      href="/docs/DomainDocsIssues_GettingStarted.html#permissions">Read
@


1.4.6.1
log
@updating branch with latest help files
@
text
@d178 1
a178 1
      href="/docs/ProjectIssues.html#permissions">Read
@


1.3
log
@added <title> tags to all files
@
text
@d1 2
a2 2
<HTML>
<HEAD>
d4 1
a4 1
<TITLE>Issue Life Cycle</TITLE>
d6 2
a7 2
</HEAD>
<BODY>
d30 32
a61 9
<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%">
  <TR>
    <TD class="Header" nowrap>An Issue's Life Cycle</TD>  
  </TR>
</TABLE>
<TABLE BORDER="0" CELLSPACING="2" CELLPADDING="2" BORDER="0" width="100%">
  <TR>
    <TD class="PlainText" VALIGN="top">
     <P>
d63 2
a64 22
       <dt><A HREF="#issuesequence">More about the sequence of an issue's status</A><br>
       <dt><A HREF="#verifyissues">Verifying issues</A>
      </dl>
     <P>
    </TD>
  </TR>
</TABLE>

<TABLE BORDER="1" CELLSPACING="2" CELLPADDING="2" BORDER="0" width="100%">
   <TR>
    <TD VALIGN="top"><H3>STATUS</H3></TD> 
    <TD VALIGN="top"><H3>RESOLUTION</H3></TD>
  </TR>
  <TR VALIGN=TOP>
    <TD class="PlainText">The <B>status</B> field indicates the general health of an issue. Only certain status transitions are allowed.</TD>
    <TD class="PlainText" VALIGN="top">The <b>resolution</b> field indicates what happened to this issue.</TD>
  </TR>
  <TR VALIGN=TOP>
    <TD class="PlainText">
      <DL>
        <DT><B><A HREF="issues_unconfirmedhelp.html">UNCONFIRMED</A></B> 
        <DD> This issue has recently been added to the database.  Nobody has
d68 2
a69 2
        <DT><B>NEW</B> 
        <DD> This issue has recently been added to the assignee's list of issues
d71 4
a74 4
     become <B>STARTED</B>, passed on to someone else, and remain
     <B>NEW</B>, or resolved and marked <B>RESOLVED</B>.
        <DT><B>STARTED</B> 
        <DD> This issue is not yet resolved, but is assigned to the proper
d76 20
a95 20
     <B>NEW</B>, or resolved and become <B>RESOLVED</B>.
        <DT><B>REOPENED</B>
        <DD>This issue was once resolved, but the resolution was deemed
     incorrect.  For example, a <B>WORKSFORME</B> issue is
     <B>REOPENED</B> when more information shows up and the issue is now
     reproducible.  From here issues are either marked <B>STARTED</B>
     or <B>RESOLVED</B>.
      </DL>
    </TD>
    <TD class="PlainText">
      <DL>
        <DD> No resolution yet. All issues which are in one of these "open" states have the resolution set to blank. All other issues will be marked with one of the resolutions below.
      </DL>
    </TD>
  </TR>
  <TR VALIGN=TOP>
    <TD class="PlainText">
      <DL>
        <DT><B>RESOLVED</B> 
        <DD> A resolution has been taken, and it is awaiting verification by
d97 4
a100 4
     <B>REOPENED</B>, are marked <B>VERIFIED</B>, or are closed for good
     and marked <B>CLOSED</B>.
        <DT><B>VERIFIED</B>
        <DD> QA has looked at the issue and the resolution and agrees that the
d103 3
a105 3
     which point they become <B>CLOSED</B>.
        <DT><B>CLOSED</B> 
        <DD> The issue is considered dead, the resolution is correct. Any zombie
d107 13
a119 13
     <B>REOPENED</B>.
      </DL>
    </TD>
    <TD class="PlainText">  
      <DL>
        <DT><B>FIXED</B>
        <DD> A fix for this issue is checked into the source code repository and tested.
        <DT><B>INVALID</B>
        <DD> The problem described is not an issue 
        <DT><B>WONTFIX</B>
        <DD> The problem described is an issue which will never be fixed.
        <DT><B>LATER</B>
        <DD> The problem described is an issue which will not be fixed in this
d121 2
a122 2
        <DT><B>REMIND</B>
        <DD> The problem described is an issue which will probably not be fixed in this
d124 2
a125 2
        <DT><B>DUPLICATE</B>
        <DD> The problem is a duplicate of an existing issue. Marking an issue
d128 2
a129 2
        <DT><B>WORKSFORME</B>
        <DD> All attempts at reproducing this issue were futile, reading the
d133 10
a142 10
      </DL>
      <P>
    </TD>
  </TR>
</TABLE>

<TABLE BORDER="0" CELLSPACING="2" CELLPADDING="2" BORDER="0" width="100%">
  <TR>
    <TD class="PlainText" VALIGN="top">
      <P><SPAN CLASS="InputHeader"><A NAME="issuesequence">More about the sequence of an issue's status</A></span>
d144 1
a144 1
      <P>What happens to an issue when it is first reported depends on
d157 1
a157 1
      <P>If you are a project member who is a developer/user/tester,
d175 1
a175 1
      <P>Some project members with additional permissions have the
d177 3
a179 3
      permissions only allow limited fields to be changed. (<A
      HREF="/docs/DomainDocsIssues_GettingStarted.html#permissions">Read
      more about IssueZilla permissions</A>). Whenever you change a
d183 7
a189 7
      <UL>
        <LI>change the component
        <LI>reassign the issue
        <LI>create an attachment
        <LI>add a dependency, or
        <LI>add someone to the CC list.
      </UL>
d191 1
a191 1
      <P>Whenever someone else makes a change to an issue or adds a
d196 1
a196 1
      <DL>
d198 2
a199 2
      <P>
<SPAN CLASS="InputHeader"><A NAME="verifyissues"></A>Verifying issues</span>
d201 1
a201 1
      <P>When issues are marked resolved, project/component owners
d208 1
a208 1
      <span class="TypewriterBold">REOPENED</span>.  <P>Be careful about
d211 1
a211 1
      proposed change as a comment <I>first</I> and to let the issue's
d216 1
a216 1
      <P>If you make a lot of useful comments to others' issues, you
d222 11
a232 6
    </TD>
  </TR>
</TABLE>

</BODY>
</HTML>
@


1.2
log
@Changed ASSIGNED to STARTED in IZ
@
text
@d1 7
d223 2
@


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

<TITLE>Issue Life Cycle</TITLE>

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


1.1
log
@moved core documentation into helm, fewer overrides need to be in instances now
@
text
@d61 1
a61 1
     become <B>ASSIGNED</B>, passed on to someone else, and remain
d63 1
a63 1
        <DT><B>ASSIGNED</B> 
d71 1
a71 1
     reproducible.  From here issues are either marked <B>ASSIGNED</B>
@


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

<TITLE>Issue Life Cycle</TITLE>

</HEAD>
<BODY>
d61 1
a61 1
     become <B>STARTED</B>, passed on to someone else, and remain
d63 1
a63 1
        <DT><B>STARTED</B> 
d71 1
a71 1
     reproducible.  From here issues are either marked <B>STARTED</B>
a215 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
@@

