assets/docs/issuezilla_tipsandtricks.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>IssueZilla tips and tricks</title>
  </head>

  <body class="docs" onload="self.focus()">
   <div class="docs" id="issuezillatipsandtricks">
    <h2>IssueZilla tips and tricks</h2>

    <div id="toc">
     <ul>
      <li><strong><a href="/nonav/servlets/HelpTOC">Help index</a></strong></li>
     </ul>

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

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

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

        <li>IssueZilla tips and tricks</li>

        <li><a href="/nonav/docs/contributing_patches.html">Contributing patches</a></li>
       </ul>
      </li>
     </ul>
    </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="#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>IssueZilla tips and tricks</title>
	</head>

	<body class="docs" onload="self.focus()">
	<div class="docs" id="issuezillatipsandtricks">
	<h2>IssueZilla tips and tricks</h2>

	<div id="toc">
	<ul>
	<li><strong><a href="/nonav/servlets/HelpTOC">Help index</a></strong></li>
	</ul>

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

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

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

	<li>IssueZilla tips and tricks</li>

	<li><a href="/nonav/docs/contributing_patches.html">Contributing patches</a></li>
	</ul>
	</li>
	</ul>
	</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="#toc">Top</a> \| <a href="/nonav/servlets/HelpTOC">Help index</a></p>
	</div>
	</div>
	</body>
	</html>