Some Hints On Using a Bug Tracker / Issue Tracker:

Working on a project for HelMUG (actually just helping a bit out, way too little time left for this), I came to the conclusion that some good tipps on using an Issue Tracker could be usefull for a lot of people, and not just those of HelMUG - the greek Mac User Group. Read on...

• Small bites, chewable size. If some issue is too big to be done in one step, then the issue will remain in the tracker for ever, the view of many forever unresolved issues will discourage the users. So if I look at an issue I should see in 1 Minute what actually has to be done, what is the "To Do".
• If one task consists of many things to do, make many issues out of it.
• Assign issues to the people who really do them / plan to do them. If people are busy, ask them if it's OK to assign to them (by Mail / phone iChat / etc.)
• The Issue Tracker is not a BBS / Forum / chat site. Discussion items like "let's meet sometimes to discuss things" or "what do you think about the menu xy" make no sense, they belong into a forum site. (And yes, there is a status "chatting", but it does not mean that we chat in the Issue Tracker.)
• Be honest about the priority. Just because something is a "hot topic" for you does not make it "critical" or "urgent".
  • "critical" is for issues that block other issues,
  • "urgent" is for things that has customers boiling over.
  • If the issue makes part of the project inoperable then it's a "bug",
  • otherwise it's either a "feature" (something we have to do to build our project)
  • or a "wish" (something we would really like to do when we have time).
• Update the status of issues.
  • Enter new issues that you are not working yourself on as "unread",
  • "chatting" while you talk with others about the way to resolve the issue,
  • "need-eg" (need example given) for bugs that you need an example on how to reproduce,
  • "in-progress" while you do things,
  • "testing" when you've done something and ask someone else to test it (but keep in mind to tell what to test and when to declare testing over),
  • "done-cbb" (done, could be better) is for issues that are done, but you would prefer to have another look at them and rework them (really, soon now, not "some day").
• Setting an issue to status "resolved" will make it disappear from the Issue Tracker listing. That's actually nice, we have done this. A short list in the Issue Tracker means a lot of things have been done. If you want to see resolved issues, klick on "Search" and search for "status" "resolved".

Q Why should I enter stuff into the Issue Tracker, anyone looking at the project will just see what has to be done.

A Not really. Not all your developers / helpers / friends may have time to go through your project and see what has to be done. Also if they did, they might end up fixing the easy todos over and over, leaving the hard issues forever unsolved.

Q I would put more stuff into the Issue Tracker / update my stuff in the Issue Tracker more often, but nobody else does that and it looks like I'm the only one, so what sense does it make?

A Obviously someone has to start. The more up to date an Issue Tracker gets, the higher is the peer pressure on others to update and the more usefull is the Tracker.

Q What issue tracker are you using?

A I'm using roundup, the best there is, simple, easy, just the right stuff, python.

Note: Due to spambots hitting like crazy on this blog entry, I had to move it to another location. This might confuse some RSS readers and some of the site structure. Sorry for the mess!