| <!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> |
| |
| |