Issue Tracker

aka Bug Tracker, Bug Tracking, Defect Tracker, Defect Tracking, Feature Request Tracking, Commitment tracker, Task Manager/Task List, To-Do List, etc.

I love an Issue Tracker Wiki

once you add Version Control System, you get a Software Forge

old notes

BugZilla may be the market leader (not counting MsExcel).

alternatives (recommended by members of a CTO list):

Remedy (Enterprise-price tag)
RT (Request Tracker) Open Source (some say it's too lite)
Atlassian JIRA (integration with their WikiEngine?)
Cerberus Help Desk http://www.cerberusweb.com/products_cerberus.php
Track It http://www.numarasoftware.com/Track-It.asp
HEAT

Paul Brown reminds us that bugs are not issues and vice versa - but in some environments that difference may not matter much

Some observations from personal experience

(with web/wiki-based Issue Tracker, plus PDA personal task lists)

You typically want a node to represent an entire Project or significant subproject/deliverable, with multiple granular tasks buried inside. So you're going to want to keep renaming your node to include the Next Action (Getting Things Done model). Which means you need to deal with (a) back-renaming all the wiki links into a node, and/or (b) divorce the nodeId/URI from its Wiki Name, so that non-wiki links (e.g. in email) to a node still work after renaming.

You want to make it easy to manage your Development Queue by changing dueDates on lots of nodes quickly. This doesn't necessarily require AJAX, though the alternative approach (id-suffix for each row-field in a single form for a single HttpPost) can be ugly.

actually, here's a different way to look at the problem: I find that I mostly think in terms of a queue, and few things have meaningful dueDates. So I think the smartest way (for my needs) to manage tasks is
- have a priority (which most systems do) (I'm inclined toward 5 levels)
- have an optional dueDate
- have a queuePosition, which is also optional (typically only used for stuff that's close enough to the "top")
- then your list is sorted by
  - items with a dueDate, within the next 7 days; within this group sort by dueDate, then priority, then queuePosition, then createDate
  - items without dueDate, or with dueDate further out than 7 days; within this group sort by priority, then queuePosition, then createDate
- when you create a new item, you explicitly assign it a priority and (optionally) a dueDate. It falls into proper list position. Default to start new items at the top of the sub-list, then you can move them down (or give user option to either put it at the top, put it at the bottom of the queued sublist, or give it no queuePosition value at all)
  - ideally have a drag-and-drop interface to re-order the list (AJAX?)
    - when you drag across priority-value boundaries it changes priority automatically; what happens to queuePosition value?
hmm, in thinking about this again, probably my bad practice is to not use priority codes well enough. If I used the top-priority code only for items that I need to be working on right now, etc. then all the date stuff would become less relevant. But I find that just doesn't work for me. Or maybe it would if there were lots more priority values: 1=do-in-next-2-hrs, 2=do-today-really, 3=do-in-next-2-days, 4=do-in-next-7-days, 5=do-in-next-30-days, 6=do-sometime...?

I keep coming back to needing a Task Hierarchy. If you're not going to have a hierarchy of separate subtask nodes, then you need a way to have each node be a long OutLining document that you can collapse/expand. That way you have a series of Next Actions.