aka [Bug Tracker], [Bug Tracking], [Defect Tracker], [Defect Tracking], [Feature Request Tracking], Commit Ment tracker, [Task Manager]/[Task List], To Do List, etc.

I love an Issue Tracker Wiki

• ZWiki has some Zwiki Tracker capabilities.

Bug Zilla 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

• [TrackIt] 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 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 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 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 Http Post) 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 an optional dueDate

  • have a priority (which most systems do)

  • have a queuePosition, which is also optional (only used for stuff that's close enough to

    • default to start new items at the top of the 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?)

    • then your list is sorted by

      • queuePosition (for those items that have it)

      • dueDate (for items that have dueDate but no queuePosition)

      • priority and createDate (for items that have neither dueDate nor queuePosition)

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

I keep coming back to needing a 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

User Options Recent Changes Help Page