WebSeitz/wikilog
Issue Tracker
Whenever any Form of Government becomes destructive of these ends, it is the Right of the People to alter or to abolish it, and to institute new Government, laying its foundation on such principles and organizing its powers in such form, as to them shall seem most likely to effect their Safety and Happiness.

(backlinks off) (map off)
(search off)
last edited by BillSeitz on Jul 14, 2008 3:00 pm

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

I love an

may be the market leader (not counting ).

alternatives (recommended by members of a list):

[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 , plus personal task lists)

You typically want a node to represent an entire or significant subproject/deliverable, with multiple granual tasks buried inside. So you're going to want to keep renaming your node to include the ( model). Which means you need to deal with (a) back-renaming all the wiki links into a node, and/or (b) divorce the nodeId/ from its , 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 , though the alternative approach (id-suffix for each row-field in a single form for a single ) can be ugly.

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 document that you can collapse/expand. That way you have a series of -s.

see also


See : | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |


 




Bill Seitz, fluxent at gmail dot com, Weblog