Taskwarrior

Welcome Cory.

I don't think we've ever discussed the concurrent versus consecutive nature of task relationships. We have spent a lot of energy thrashing out task dependencies, but not to the point where we have a clear plan to implement them. I think what you are describing is a combination of two things we haven't got right yet: dependencies and "next".

Dependencies

The idea of dependent tasks is a powerful one, because it closely mimics reality. Of course you need the wedding license before the ceremony, and task dependencies are an ideal way of representing this. The difficulties can be summarized with the following questions, none of which we have answered to our satisfaction:

- Should task prevent 3 from being marked as done before 2? Or should it merely warn?
- If 3 is completed before 2, should it break the dependency, or reject the command?
- If you delete 2, should task offer to delete 3? Or should it make 3 dependent on 1?
- If you mark 3 as completed, should that automatically mark 1 and 2 as completed also?

I think we need a clear and unambiguous model of what a dependency is. The problem here is that we would love to support dependent tasks, but there are a lot of odd corner cases that must be considered and resolved. We wouldn't want to implement something that causes a great deal of confusion. Perhaps your fresh approach can offer some clarity?

Next

We have been developing an algorithm for the "next" report. This algorithm would combine things like due dates, priority etc and determine an urgency for each task, then present a subset of urgent tasks. If dependencies were implemented, then we could incorporate them into the algorithm. We have a "next" report now, but it doesn't have the sophistication that this feature requires yet, and so we'll be replacing it. Improving our "next" report will make us more credible among stricter GTD folks.

Hi Paul,

If you can bear the insolence, I'd be happy to weigh in.

When a project or subproject has been marked as consisting of consecutive tasks (or subprojects), all this means is that, for this particular project, order is important. If task 1 appears before tasks 2 and 3, it isn't necessarily the case that task 2 is absolutely dependent on task 1 and task 3 is absolutely dependent on task 2, only that there is some sort of implied progression.

- Task shouldn't prevent or warn the user if he or she attempts to mark 3 as done before 2. Time-management software shouldn't shackle its users.
- If task 3 is scheduled to be performed after task 2 and task 2 is scheduled to be done after task 1, then if task 2 is deleted or completed then task 3 should immediately follow task 1. If this 'dependency' is represented only by the order in which the tasks are listed, then nothing needs to happen on the UI side except for the removal of task 2.
- If the user modifies/deletes/completes 1, task shouldn't touch 2 or 3.

Regarding Next, I'm an adherent to the GTD idea that priorities (in real life) are too complex and dynamic to represent within task management software¹, so without some type of dependency implementation I can't really benefit from a Next Actions report. As a workaround, I'm numbering the descriptions of projects containing tasks which need to be done consecutively, which works for tasks but not projects with subprojects. As an aside, that's something else I'd like to see -- subprojects should appear as tasks, albeit multi-step tasks, within their parent tasks.

Thanks a lot for all of your hard work -- I feel as though I've finally found task-management software which conforms to the needs of its users, rather than the other way around.

Cory

[1] http://www.davidco.com/blogs/kelly/archives/2009/05/