[hotproject-devel] proposal: heirarchical task semantics

[Jamey S. <ja...@sh...>]

I've been thinking about how to simplify hotProject implementation, and
how to support scheduling better.

The only reason we're using a tree of tasks is to support grouping tasks
into logical chunks, right? So here's what I propose.

Let's make two types of nodes in the task tree: groups and tasks. Tasks
can not have subtasks, but groups can contain both groups and tasks. The
only property a group posesses is a name.

I see several advantages.

getElementsByTagName works. We wouldn't have to worry about it finding
things from sub-tasks, because there wouldn't be any. This should
dramatically simplify the code.

The semantics are clear for scheduling: there is only a set of tasks,
not a tree. Scheduling clearly does not need to change the structure of
this tree, either.

Information about start and finish dates and progress can be propagated
up the tree in fairly obvious ways, without confusion due to that same
data having been set higher in the tree. This would make for useful
reports: the user can analyze the project at whatever level is useful.
(e.g., "show me progress for all groups at depth 1".)

I see one issue: user interface. Now users have to be able to request
either a group or a task when adding, and a different editor (supporting
only group name) has to be added for groups. The right type of editor
has to be invoked depending on which kind of node is selected, when the
edit button is pressed.

So. Comments? Especially, Bart, does this do good things for scheduling?
And everyone else, have I missed some reason that this would make your
code harder, or that this would be bad for project management?
-- 
Jamey Sharp <ja...@sh...> - http://jamey.is.dreaming.org/