Additional resources about issues: 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