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

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

1.3
date	2001.03.16.23.49.46;	author lori;	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.5
log
@html usage revision
@
text
@  <div class="docs" id="issuezillatipsandtricks">
   <h2>IssueZilla tips and tricks</h2>

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

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

      <ul>
       <li><a href="issue_lifecycle.html">The issue life cycle</a></li>

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

       <li><strong>You are here:</strong> IssueZilla tips and tricks</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>

   <p>Here are a few guidelines to help you effectively make use of issue tracking in your collaborative development projects.</p>

   <ul>
    <li>When you see an issue come through email channels, this is an indication that you have either been assigned or cc'd on a particular issue. Don't ignore it!</li>

    <li>Make frequent use of the "My issues" option in the IssueZilla tool bar. This list displays all project issues assigned to you.</li>

    <li>If you are assigned an issue and you have the bandwith, <strong>it is your responsibility to investigate the issue</strong>. If it has been given a milestone, is also your responsibility to "fix" the issue in the proper order by the designated date, <i>or</i> to communicate the reasons for not meeting the milestone date using the issue "comments" field.</li>

    <li>If you are assigned an issue and you do <i>not</i> have enough time to do the work, it is your responsibility to communicate (through the description field) your inability to complete the assignment.</li>

    <li>Don't just go and fix issues that have not been given a milestone. It is extremely important for the project leader to carefully consider the impact the milestone's changes might have on the codebase. An issue without a milestone indicates that other factors have yet to be determined.</li>

    <li>Proceed through your issues in order sorted by milestone, then by priority. If it makes sense to modify the sequence that's fine, just don't blow the milestone!</li>

    <li>When an issue is completed (you've written the code, etc.), if applicable check it into CVS and mark the issue "fixed." Include a comment on how you did it. Fixed=Checked In!</li>

    <li>Try not to batch up a bunch of issue fixes and check them in all at once. This wreaks havoc on the project administrator's ability to track status and prohibits granular roll backs, etc.</li>

    <li>Feel absolutely positively free to add more issues to the list as you realize them. <strong>Just be sure to query the issue database first to avoid entering duplicate issues!</strong></li>

    <li>Post any and all comments/notes pertaining to a particular issue using the description field. This way anyone who is handling an issue can easily see its history and get to work on it. The issue tracker <strong>must</strong> reflect all of your changes for project release notes to be accurate.</li>

    <li>Refer to the issue tracker on an almost constant basis. In practice you'll find that this is a very efficient way of seeing what is expected of you rather than sifting through emails.</li>
   </ul>

   <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.4
log
@extensive markup rework - first pass toward house xhtmlification
@
text
@d1 2
a2 9
<!DOCTYPE html PUBLIC "-//CollabNet//DTD XHTML 1.0 Transitional//EN"
"http://collabnet.com/dtds/collabnet_transitional_10.dtd">
<html>
 <head>
  <title>Issuezilla Tips and Tricks</title>
<style type="text/css">
 div.c1 {margin-left: 2em}
</style>
 </head>
d4 2
a5 3
 <body>
  <div class="docs" id="docid">
<h2>IssueZilla tips and tricks</h2> 
d7 3
a9 1
  <p><strong>Additional resources about issues: Index</strong></p>
d11 2
a12 3
  <div>
   <dl>
    <dt><a href="ProjectIssues.html">Project Issues help</a></dt>
d14 1
a14 1
    <dd><a href="issue_lifecycle.html">The issue life cycle</a></dd>
d16 1
a16 1
    <dd><a href="issuewritinghelp.html">Issue writing guidelines</a></dd>
d18 5
a22 1
    <dd><strong>You are here: IssueZilla tips and tricks</strong></dd>
d24 3
a26 1
    <dd><a href="contributing_patches.html">Contributing patches</a></dd>
d28 1
a28 4
    <dt><a href="/servlets/HelpTOC">Back to main Help index</a></dt>
   </dl>
  </div>
  
d30 2
a31 1
  <p>Here are a few guidelines to help you effectively make use of issue tracking in your collaborative development projects.</p>
d33 1
a33 3
  <ul>
   <li>
    When you see an issue come through email channels, this is an indication that you have either been assigned or cc'd on a particular issue. Don't ignore it! 
d35 1
a35 2
    
   </li>
d37 1
a37 2
   <li>
    Make frequent use of the "My issues" option in the IssueZilla tool bar. This list displays all project issues assigned to you. 
d39 1
a39 2
    
   </li>
d41 1
a41 2
   <li>
    If you are assigned an issue and you have the bandwith, <strong>it is your responsibility to investigate the issue</strong>. If it has been given a milestone, is also your responsibility to "fix" the issue in the proper order by the designated date, <i>or</i> to communicate the reasons for not meeting the milestone date using the issue "comments" field. 
d43 1
a43 2
    
   </li>
d45 1
a45 2
   <li>
    If you are assigned an issue and you do <i>not</i> have enough time to do the work, it is your responsibility to communicate (through the description field) your inability to complete the assignment. 
d47 1
a47 2
    
   </li>
d49 1
a49 2
   <li>
    Don't just go and fix issues that have not been given a milestone. It is extremely important for the project leader to carefully consider the impact the milestone's changes might have on the codebase. An issue without a milestone indicates that other factors have yet to be determined. 
d51 2
a52 2
    
   </li>
d54 6
a59 40
   <li>
    Proceed through your issues in order sorted by milestone, then by priority. If it makes sense to modify the sequence that's fine, just don't blow the milestone! 

    
   </li>

   <li>
    When an issue is completed (you've written the code, etc.), if applicable check it into CVS and mark the issue "fixed." Include a comment on how you did it. Fixed=Checked In! 

    
   </li>

   <li>
    Try not to batch up a bunch of issue fixes and check them in all at once. This wreaks havoc on the project administrator's ability to track status and prohibits granular roll backs, etc. 

    
   </li>

   <li>
    Feel absolutely positively free to add more issues to the list as you realize them. <strong>Just be sure to query the issue database first to avoid entering duplicate issues!</strong> 

    
   </li>

   <li>
    Post any and all comments/notes pertaining to a particular issue using the description field. This way anyone who is handling an issue can easily see its history and get to work on it. The issue tracker <strong>must</strong> reflect all of your changes for project release notes to be accurate. 

    
   </li>

   <li>Refer to the issue tracker on an almost constant basis. In practice you'll find that this is a very efficient way of seeing what is expected of you rather than sifting through emails.</li>
  </ul>

  
  
 <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.3
log
@added index
@
text
@d1 2
d4 6
a9 1
<head>
d11 3
a13 1
<title>Issuezilla Tips and Tricks</title>
d15 1
a15 2
</head>
<body>
d17 3
a19 97
<span class="Header" nowrap>IssueZilla tips and tricks</span>  
<p>
    <span class="PlainText"><strong>Additional resources about issues: Index</strong>
<ul>
	<dl>
	<dt><a href="ProjectIssues.html">Project Issues help</a>
		<dd><a href="issue_lifecycle.html">The issue life cycle</a> 
		<dd><a href="issuewritinghelp.html">Issue writing guidelines</a>
		<dd><strong>You are here: IssueZilla tips and tricks</strong> 
		<dd><a href="contributing_patches.html">Contributing patches</a>
	<dt><a href="/servlets/HelpTOC">Back to main Help index</a>
	</dl>
</ul>
<hr noshade size=1>
     <p>
Here are a few guidelines to help you effectively make use of issue tracking in your collaborative development projects.

     <ul>

      <li>When you see an issue come through email channels, this is
      an indication that you have either been assigned or cc'd on a
      particular issue. Don't ignore it!

      <p>

	<li>Make frequent use of the "My issues" option in the
	IssueZilla tool bar. This list displays all project issues
	assigned to you.

	<p>

      <li>If you are assigned an issue and you have the bandwith,
      <strong>it is your responsibility to investigate
      the issue</strong>. If it has been given a milestone, is also your
      responsibility to "fix" the issue in the proper order by the
      designated date, <i>or</i> to communicate the reasons for not
      meeting the milestone date using the issue "comments" field.

      <p>

      <li>If you are assigned an issue and you do <i>not</i> have enough time to do the work, it is your responsibility to communicate (through the
      description field) your inability to complete the assignment.

      <p>

      <li>Don't just go and fix issues that have not been given a
      milestone. It is extremely important for the project leader to
      carefully consider the impact the milestone's changes might have
      on the codebase. An issue without a milestone indicates that
      other factors have yet to be determined.

      <p>

      <li>Proceed through your issues in order sorted by milestone,
      then by priority. If it makes sense to modify the sequence
      that's fine, just don't blow the milestone!

      <p>

      <li>When an issue is completed (you've written the code, etc.),
      if applicable check it into CVS and mark the issue "fixed."
      Include a comment on how you did it. Fixed=Checked In!

      <p>

      <li>Try not to batch up a bunch of issue fixes and check them in
      all at once. This wreaks havoc on the project administrator's
      ability to track status and prohibits granular roll backs, etc.

      <p>

      <li>Feel absolutely positively free to add more issues to the
      list as you realize them. <strong>Just be sure
      to query the issue database first to avoid entering duplicate
      issues!</strong>

      <p>

      <li>Post any and all comments/notes pertaining to a particular
      issue using the description field. This way anyone who is
      handling an issue can easily see its history and get to work on it.
      The issue tracker <strong>must</strong>
      reflect all of your changes for project release notes to be
      accurate.

      <p>

      <li>Refer to the issue tracker on an almost constant basis. In
      practice you'll find that this is a very efficient way of seeing
      what is expected of you rather than sifting through emails.

     </ul>
 
<p>
 <hr noshade size=1>
<a href="ProjectIssues.html">Back to Project Issues help</a><br>
<a href="/servlets/HelpTOC">Back to main Help index</a>
d21 84
d107 2
@


1.2
log
@added <title> tags to all files
@
text
@d1 2
a2 2
<HTML>
<HEAD>
d4 1
a4 1
<TITLE>Issuezilla Tips and Tricks</TITLE>
d6 2
a7 17
</HEAD>
<BODY>
<TABLE BORDER="0" CELLSPACING="1" CELLPADDING="3" BORDER="0" WIDTH="100%">
  <TR>
    <TD class="Header" nowrap>IssueZilla tips and tricks</TD>  
<TD CLASS="StatText" ALIGN="right"><A HREF="DomainDocsIssues.html">Back to main
IssueZilla page</A>
</TD>
  </TR>
</TABLE>
<TABLE BORDER="0" CELLSPACING="2" CELLPADDING="2" BORDER="0" width="100%">
  <TR>
    <TD class="PlainText">

     <P>
Here are a few guidelines to help you effectively make use of issue
tracking in your collaborative development projects.
d9 16
a24 1
     <UL>
d26 3
a28 1
      <LI>When you see an issue come through email channels, this is
d32 1
a32 1
      <P>
d34 1
a34 1
	<LI>Make frequent use of the "My issues" option in the
d38 1
a38 1
	<P>
d40 3
a42 3
      <LI>If you are assigned an issue and you have the bandwith,
      <span class=InputHeader>it is your responsibility to investigate
      the issue</span>. If it has been given a milestone, is also your
d44 1
a44 1
      designated date, <I>or</I> to communicate the reasons for not
d47 1
a47 1
      <P>
d49 1
a49 2
      <LI>If you are assigned an issue and you do <I>not</I> have the
      bandwidth, it is your responsibility to communicate (through the
d52 1
a52 1
      <P>
d54 1
a54 1
      <LI>Don't just go and fix issues that have not been given a
d60 1
a60 1
      <P>
d62 1
a62 1
      <LI>Proceed through your issues in order sorted by milestone,
d66 1
a66 1
      <P>
d68 2
a69 2
      <LI>When an issue is completed (you've written the code, etc.),
      if applicable check it into cvs and mark the issue "fixed."
d72 1
a72 1
      <P>
d74 1
a74 1
      <LI>Try not to batch up a bunch of issue fixes and check them in
d78 1
a78 1
      <P>
d80 2
a81 2
      <LI>Feel absolutely positively free to add more issues to the
      list as you realize them. <span class=InputHeader>Just be sure
d83 1
a83 1
      issues!</span>
d85 1
a85 1
      <P>
d87 1
a87 1
      <LI>Post any and all comments/notes pertaining to a particular
d89 2
a90 2
      handling an issue can easily see its history and get crackin'!
      The issue tracker <span class=InputHeader><I>must</I></span>
d94 1
a94 1
      <P>
d96 1
a96 1
      <LI>Refer to the issue tracker on an almost constant basis. In
d100 6
a105 5
     </UL>
    </TD>
  </TR>
</TABLE>

d107 2
a108 2
</BODY>
</HTML>
@


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


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

<TITLE>Issuezilla Tips and Tricks</TITLE>

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


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

<TITLE>Issuezilla Tips and Tricks</TITLE>

</HEAD>
<BODY>
a97 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
@@

