Nested or dependent tags

Hi Andrei,

Thanks for all your efforts on both the SW and community.

Feature request is to nest tags such that simply entering a daughter tag to an action it will still show when filtering for the parent.

Example behaviour:
Area = Work

  • Area of Focus label = Project A
    • Context = @Bob

Where each level is the daughter to the proceeding and if context @Bob is populated the tags Project A and Work are automatically applied too. That way when I filter on all my Work actions or all my Project A actions, I will still see that I need to chat with Bob.

Reason for automating the feature:
This can be done manually (I do it currently) but is prone to human error. All it takes is to miss one of the three tags and the filtering system cannot be relied on 100% - which would otherwise be one of the highlights of Everdo

I understand what you mean. This has been suggested before and I agree it’s useful. However I decided not to make it a priority for now. Unfortunately this feature is quite difficult to add at this point and prone to introducing defects.

Glad it makes sense. Hope to see it on the priority list at some point :smiley:

How easy is it to achieve for tasks? Is it easier than for tags?

At present we only have 2/3 levels of tasks - project, task, checklist items.
Although that is largely a feature of GTD - and probably one of my few criticisms of it.

Although more of a project management & collaboration tool than To Do manager, I think that quire.io do I really good job of allowing infinite nesting. I find that this is how my mind works - there may be 2-5 high level items to complete a project but when you start defining this you find there are many more subtasks (and dependencies).

In contrast, with the pancake like GTD you end up having to create multiple projects that all sit alongside each other - when in effect they are “workpackages” of a single higher level project.

Would you like me to submit this as a feature request in its own right?

Project nesting is suggested often, but it will definitely not be added any time soon, if ever. See, for example, Ability to group/sort projects, create sub-projects

Noted.

What about dependencies between tasks e.g. cannot start until, cannot end before?
Not strictly part of the GTD methodology but then David Allen was also writing at a time when the corporate world was far more siloed and BAU

A start date or someday status or a tag could be used to mark such items. Each case is different, do you have a specific example in mind?

In the same way you have the drop down field for Project (including the ability to leave unassigned). So too you could have a drop down “Dependency” field with the list of other actions to select from

I get that to some extent this is covered by making a Project sequential but:
a) What about fishbone type projects with some in parallel and others sequential
b) The ability to make whole projects dependent on completion of other projects
c) Linking standalone actions that are still dependent on others

I can appreciate the difficulty of creating infinitely nestable projects and tasks. I submit that perhaps the following dependency issue might solve 80% of the user needs.

task 1: build shelf
task 2: get wood

Task 1 is dependent on task 2. Most of this is handled simply by the ordering within a project, so Everdo works well. Seeing that a task is below another task in a project flows naturally with ordering that project in roughly order of Next action.

The infrequent, but powerful cases are when there are cross project dependencies.

Project: Redo living room; task 1: build shelf (dependent task)
Project: Build portable sawmill; task 2: get wood (blocking task)

Everdo in-project ordering doesn’t help here. task 1 will show up in “Redo living room” project despite not being able to act on it and without clues as to the dependency.

Suggestion:

Allow selection of a task in “Waiting For” as one of the things being waited for (in addition to the tags currently available). Inherently tasks waiting for other tasks disappear from Next views in projects. When the blocking task is completed or deleted, the dependent task is moved to Next status.

This proposal doesn’t solve everything and does require some thinking on the easiest to implement and use UI, but it seems much simpler than a general approach that can handle all dependency use cases.

However, I believe 80% of the dependency use cases are covered with the existing in-project ordering in Everdo, so this feature would fall well below features with higher value.