Sometimes it becomes clear that a Next Action is premature. In Tracks I’ve been dealing with this by sending them into the future, to be handled in the same context but in the tickler. That’s not quite right, and it doesn’t capture the dependency that makes them premature.
Ticket #373 suggests promoting actions to subprojects. Viewing a project and its subprojects makes sense in a top-down way. From a project’s page, Deferred Actions could list what an action depends on instead of the time-to-defer. And the Active Projects list on the right-hand side could have subprojects listed in an indented tree.
But I do my work from the main page / contexts lists, and subprojects (as described) don’t fit in to contexts.
The most common answer for this is to hide the dependencies in the Tickler, as with the date-deferred actions. I have an additional idea I think might be useful.
“Context” means a state in which you can address particular Todos. For canonical GTD, the list of items in a context should all be next actions. I’m opposed to the idea of displaying nested tasks in the context interface- followup actions aren’t valid in the current context.
What’s the proper context for the followup action? I think it has two required contexts: the standard context, and also the action that must be completed first. Each of these provide valuable perspectives on my work. Imagine treating actions as contexts- starting from the question “Once I’ve completed this action, what is possible?” This gets at an additional layer of the project that is otherwise only implicitly addressed in GTD.
David Allen describes making “vertical sweeps” over a project, and “horizontal sweeps” over contexts. Project-specific contexts seem to get at the innards of a project in a different sort of horizontal sweep.
In the same vein, subprojects seem valid candidates for contexts. “Once the project is at this stage, what is possible?”
Tying these together: I think there doesn’t have to be a difference between a subproject and an action depending on a prior action. One is explicitly created from the Project View, and the other is implicitly promoted from a Next Action. Both can be completed, both add structure to the project, and both expose a new context for future actions.
User Interface:
The “Show from” field becomes “Starting:” and is allowed to contain either a date or a precondition Next Action. Typing in the field will auto-fill with the names of current actions in the project.
The list of projects on the right-hand side will have nested subprojects (either always visible, or only for the currently active project; possibly the current project would be listed in a “Current Project” section above “Active Projects”). Viewing a subproject brings up a context list page, displaying the next actions in the subproject. Because subprojects can be completed, they have a checkbox next to their title at the top. The master list of projects on the right-hand side could change the colour of the subproject depending on whether it is complete.
The subproject appears in the Project Page and its Context with an icon to show the count of dependent items (possibly like the red count of actions on the upper-left corner of any page).
When a subproject is incomplete, its Next Actions are listed on the project page as Deferred with their precondition instead of the days-to-defer.
Completing a subproject exposes all of its Next Actions in the appropriate context and on the Project’s list of actions. The subproject moves to the Completed Actions. It is still listed in the subprojects list on the right-hand side, and it can still be linked as a context.
