IssueZilla tips and tricks

Additional resources about issues: Index

Project Issues help
  The issue life cycle
  Issue writing guidelines
  You are here: IssueZilla tips and tricks
  Contributing patches
Back to main Help index

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

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

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

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

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

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

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

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

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

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

- 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 must reflect all of your changes for project release notes to be accurate.

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

Back to Project Issues help
Back to main Help index