Dependencies¶

discussion¶

Task hierarchy is denoted by number of hyphens. The assumption is that dependent tasks need to be completed before parent tasks.

- parent (1) (task 100)
-- child (1.1) (task 108 dep:100)
-- child (1.2) (task 112 dep:100)
--- grand child (1.2.1) (task 115 dep:112)
-- child (1.3) (task 120 dep:100)
--- grand child (1.3.1) (task 122 dep:120)
---- great grand child (1.3.1.1) (task 125 dep:122)

Questions:
- How does one add a child element between 1.1 and 1.2?
--- task add dep:100, let sort put it "between"
- If one deletes 1.3.1, what happens to 1.3.1.1?
---you are attempting to delete a task with dependencies, are you sure ? (Y/n)
---should links to this task be [D]eleted or moved to [G]randparents (d/g)
- Promotion: 1.2.1 to the next level up, e.g., 1.4
--- task 115 dep:100
- Promotion: how does one promote 1.1 to a new parent task?
---task 108 dep:0
- Promotion: what happens to child tasks when a parent is promoted?
--- parent task has new dep:<ID>, child task unchanged
- If I mark 1.3.1 as done, does 1.3.1.1 also get marked done? (pb)
---you are attempting to mark as done a task with dependencies, are you sure ? (Y/n)
---should links to this task be [d]eleted or moved to [g]randparents ? (d/G)
- If I mark 1.3.1 as started, does 1.3.1.1 also get marked done?
no (djp)

(I think) the only actions that force modification of dep:<ID> are delete and done of a task upon which other task(s) depend. Any time a task <ID> changes (task moved/ deleted) causing unresolved dep:<ID> it forces a small set of dialogs to resolve or delete broken links, unless there is some default action otherwise dep:<ID> is just another value of just another attribute. display logic is a whole nuther kettle o fish. (djp)
[This probably also applies to other commands] (pb)

much of the confusion illustrated above is a result of the "standard" outline numbering scheme. If we steadfastly maintain ID as identifier, then it is a matter of determining what, if anything, the new dep:<ID> should be.

[pb: I think the previous two sentences are very important. It is simple if we think dep:<ID>, and it is most certainly NOT simple if we think outline, or acyclic graph.]

Previous and Existing Examples

I am not an emacs person, but I looked into emacs outline mode long ago when I thought I was going to write my own version of task. Outline mode is (probably) more robust than needed, but the code is old/stable/complete. Might be worth a moment of time.

I also came across various tree implementations that reminded me that I did not pay close enough attention in school when we were doing data structures.

I also realized that MS Powerpoint's bullet/outline system is logically weird, but works well because one has constant visual feedback (and fast undo). For a command line application, a different set of assumptions might need to be made, but I did not think this through very hard.

MS word (shudder) has a very nice outline mode, but my first and all-time favorite was in a ROM chip for the Radio Shak model100, called "thought. I currently use vimoutliner in text world and freemind, in a GUI. I don't think we have much to learn from any of these :-) (djp)

for an example of hierarchy rendered in console graphics, look no further than the display of threading in mutt.

the todo.sh list had a short discussion on this topic a while ago <http://tech.groups.yahoo.com/group/todotxt/message/2094>. A few interesting points raised. there is a reference to existing python and shell code that might be of interest. (tcy)

Known Issues

Is a hierarchy the right way to look at this? Multi-tree?

Dependencies result in hierarchy, it's inescapable (djp)

Furthermore, having dependent tasks results in an acyclic graph. The hope is that is really is acyclic, and not cyclic. Should cyclic dependencies be prevented by task? I think so. (pb) me too (djp)

What happens when the user really wants a task to have more than one parent. For example, a child task may need to be completed before two other tasks can be completed. That doesn't fit in a tree structure. (pb) easy; no can do! for sanity sake, a task can only depend on one other task, but any number may depend on it (djp)

Implementation Points

creation of dependent tasks should be easy;
task add dep:22 thingtodo after task22
but the ball we need to keep our eye on is what happens when the task, or the task referred to, is modified, so that when ANY task is modified, any dependencies must be resolved. I'm thinking at this point, of building a matrix (spreadsheet) to see how the logic resolves using google docs (http://spreadsheets.google.com/ccc?key=rqE3B8xby70pwe0gGpOvbQQ) and after some initial head scratching, I think it's easier than we might fear. (djp) now published ? (djp) i don't have permission; just asked the system to request permission from pb (tcy)

/>

a task with dep:<ID> AND recur:anything should not be allowed, due to brain-busting complexity, but a task should be allowed to depend on a single occurrence of a repeating event, with no problems.

dialogs
the user interacts with dialogs to resolve any ambiguity resulting from optional outcomes (bat-gabble)
exact language TBD, but let's list inevitable dialogs and kick around options;

You are about to delete <ID><description> - it has # dependent(s),
<ID><description>
Are you sure (Y/a/n/d) (y)es to delete task and dep:, (n)o to cancel, (a)sk each time, (d) to delete all tasks
ok, it's complicated ;-)

That looks pretty good, with wording TBD.

tcy asks: does this mean that task will/should/might create new dependent tasks if a set of dependent tasks is edited. I know that the answer to this is yes, but what do users expect?
djp: I think the answer is actually no. I don't think task itself should create any dependencies, only those that you specify exist. now when the target of that dependency is broken (deleted, done) then the link needs to be resolved (child task connected to grandparent, instead) or the dep:<ID> (now points to nowhere) should be removed.
if you have 1->2->3->4->5-> and delete 3, do you want 1,2 and 4,5 to exist as separate entities or for 1,2 to link directly to 4,5? the answer is probably "it depends," which means that there is another layer of dialogs asking the user what to do? Necessary evil or are there alternatives?
The alternative is to stop thinking of those things as a chain, which they appear to be, and start thinking of them as five things with a dep:<ID> attribute that point to one task, and are just sorted into 1 to 5, alpha-numerically, by the listing function.

tcy: I must not quite get the way you have dep:<id> implemented (in your head). or maybe my example is not quite clear. I think in my example, there are actually several tasks that are dependent on a single, previous task. the listing in my mind should not be alpha-num, but based on the dependency order. so in the 1 to 5 example above, i would expect that 5 would always be listed after 4 because 4 was dependent on 5 being completed (think remove lug nutes from wheel, then remove wheel from car, change spare tire). i agree with you if the example is 1:2,3,4,5 as in clean house:vacuum, pick up books, windows.. where the vacuum, books and windows are not necess tied to one another, but are all subsets of the parent "clean house."
djp: ahh, I DID misinterpret the example above, and if that chain is broken (modification causing orphaned dep:<ID>) then they must be reconciled using dialogs. If the task being removed has both dep:<ID> to and from it, then the resultant dialog should offer to connect the child to the grandparent, or delete the link.

tcy: that said, if constructed correctly, a chain of dependent actions should automatically and naturally disassemble if a middle element is removed (stretching... in the example with the tire, imagine sending the car to a mechanic to change the tire instead of doing it oneself. the mian task of "fix tire so i can drive" remains, but several sub-tasks might be missing, but still pertinent)