aka Bug Tracker, Bug Tracking, Defect Tracker, Defect Tracking, Feature Request Tracking, Commit Ment tracker, Task Manager/TaskList, ToDoList, etc.
I love an Issue Tracker Wiki
ZWiki has some Zwiki Tracker capabilities.
BugZilla may be the market leader (not counting MsExcel).
alternatives (recommended by members of a CTO list):
RemEdy (Enter Prise-price tag)
RT (Request Tracker) Open Source (some say it's too lite)
Atlass Ian JIRA (integration with their Wiki Engine?)
Cerberus Help Desk http://www.cerberusweb.com/products_cerberus.php
Paul Brown reminds us that bugs are not issues and vice versa - but in some environments that difference may not matter much
<hr>
Some observations from personal experience
(with web/wiki-based IssueTracker, plus PDA personal task lists)
You typically want a node to represent an entire ProJect or significant subproject/deliverable, with multiple granual 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 WikiName, 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 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 Out Lining document that you can collapse/expand. That way you have a series of Next Action-s.
see also Mind Map As To Do List
<hr>