GNOME Bugzilla – Bug 143387
Support for task splits (automatically to resolve resource conflicts or manually).
Last modified: 2021-06-09 20:30:55 UTC
See also, bugzilla, 136789. While working on my resource allocation with priority functuional specification it struck me that one of the best ways of not overallocating resources of an already-started task is to split the lower prioirty task for the duration of the higher priority task. I'd already added stuff into the other bugzilla (136798) but these problems are quite different. I'm thinking that if we had an xml elements of, "splits" and "split" then we could use this to split up a task to allow resources to be reused on other tasks; automatically. <task id="14" name="Fix roof on shed" note="" work="128000" start="20040124T104500Z" end="20040210T104500Z" percent-complete="0" priority="0" type="normal" scheduling="fixed-work"> <predecessors> <predecessor id="1" predecessor-id="13" type="FS"/> </predecessors> <splits> <split type="priority" start="20040124T104500Z" end="20040125T104500Z" /> <split type="priority" start="20040125T104500Z" end="20040126T104500Z" /> <split type="priority" start="20040130T104500Z" end="20040201T104500Z" /> <split type="priority" start="20040206T104500Z" end="20040210T104500Z" /> </splits> </task> The type=priority is to show that this split gets recalculated when priority is recalculated. You can also have a type of manual too which won't be recalculated. The assumption is that the resources get allocated for this task and is the same for each split though actual work only takes place on the time periods shown. The gantt would adopt a similar [===].......[=======]....[==]...[==] style that other planning tools have for split tasks. Delete, move and resource allocations affect all splits as well as any related (sibling or relation) task changes of work, duration, priority for the type=priority.
An obvious enhancement is that by implication a task split means that the resources are allocated but units are '0'. The obvious extention is that for the duration of a split just 1 (or many) resources could be zero'd) as opposed to the implication of all. This solves the problem of resource contention when two tasks share just 1 resource. A split without stating which resources are zero'd would leave the other uncontended resources without work to do; in reality they would do work but as far as planner is concerned what they are doing is not reflected in the plan. For the display we could show narrower height gantt bar e.g., [=======----========] We either enhance the split type of priority of create a new one e.g. resource.
If we created a "resource" split then we could use this to... - render the gantt differently with either the .... dots for deadtime of smaller sized vertical bar for under-resourced time, e.g. in my best ASCII art, compare [====][......][=====] to [====-----======] - switch the calculation for duration differently (more complex with resource splits as some resource may still be available.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/World/planner/-/issues/60.