Approaches for GTD with or without `org-roam` or `org-gtd`?

Troubleshooting
1

The central problem, as I see it, is this: projects and tasks form a graph. A task or subproject might be shared between multiple projects. Next Actions are a subset of TODOs. They are sink nodes in graph theoretic terms.

I think tracking these dependencies would be super helpful for me in prioritizing where my time should go. For example, cleaning up the garage might not seem like a high priority – except it that it blocks a home improvement project that needs to be completed by a certain date.

Next Actions and Projects

I like how org-gtd automates tracking of next actions and correctly shows only the unblocked tasks. But its notion of task dependencies is linear, and it’s not clear that tasks can depend on other tasks across projects, or if projects can have subprojects.

This is what drew me to org-roam. I like org-roam for the way it assists linking tasks and exposing the underlying graph structure in a performant way. I want to build a GTD workflow on top of this, one way or another.

It’s not super clear to me how org-roam and org-gtd can be used with each other in any kind of obvious way. But I am studying both code-bases to see what I can learn from them. I have many years of experience in software development, and many years of using emacs as my primary editor, but only a passing familiarity with emacs lisp and emacs internals.

Has anyone gone down this path?

What I’m Trying to Get To

I’m trying to blend both approaches. Something with high-level automation around the GTD workflow, as org-gtd does, but which models task-management as a graph of task nodes. I can see org-roam as a useful dependency here.

In a pure implementation, every task would be a proper node with an ID. From this perspective, a project is simply a task with a dependency on at least one active subtask. But I suppose it could be useful to explicitly distinguish a Project from a Task, from an Area of Interest, from a Horizon, and so on.

I would settle for something slightly kludgier in the name of code re-use and getting up and running quickly. But the the task sharing / cross-task dependencies are key, for when a task in one project is blocked by completion of another task in another project, which seems to come up all the time for me.

2

I would say, don’t worry about the graph of dependencies between actions. In my opinion, it is not worth it. Here is a quick overview of how I do PARA/GTD with org-roam. I am happy, and if something does not work, I try to adapt org-roam to my needs rather the other way around.

  • My files are divided into PARA (areas, projects, archival and reference)
  • An area and a project are very similar, but projects have a precise deadline
    • Areas and Projects have an Actions subnode. All TODOs go there.
    • I do use NEXT and TODO, but I find that scheduling is usually sufficient that I don’t
      use NEXT most of the time
  • I have a daily node (the file is by week). Every day I created a node for the current day
    • the daily node has Actions for the day that are not part of a PARA node.
    • the weekly node has Actions for the week
    • If the actions are not carried over in that day/week, they are moved to their corresponding projects
      or the next day/week
  • I have a bunch of org-roam templates:
    • One for Project
    • ONe for Area
    • One for Reference
    • ONe for capture to inbox (the inbox is the weekly inbox)
    • One for capture to an existing node’s actions
    • Other capture templates for specific purposes (eg. logging URLs that are important to keep)
  • About Projects/area
    • I have a TODO tag for each: AREA, PROJ and one for finished projects FPROJ
    • each project/area gets a directory (so I can dump materials to it)
    • only project, areas and the current week file can have TODOs
    • the agenda operates dynamically on these files (via a dynamically created list of nodes)
    • The agenda is how I find things that need to be done. I am trying to every day start the day and end the day by reviewing the agenda.
    • I have some commands (basically filtering org-roam-node-fine) to visit only Area/Projects
  • Weekly/Monthly review
    • I have some ad-hoc SQL queries that I run (via elisp) to get a list of projects and areas.
    • Each Area/project has an property “REVIEWED” that tells me when was the last time it was reviewed
      this helps with the weekly and monthly review
  • I have some snippets for creating some repetitive sections instead of a template (e.g. my daily startup/shutdown
    routines)
  • I manage the tasks dependencies in my brain. i have tried org-gtd in the past, but sometimes is just annoying. If I
    finish a task, the next one might not be necessarily the next. And most of the time it is not worth my time to
    edit the graph of actions. I can simply complete one and choose/schedule the next one. I am more for GTD in this regard: review and choose
    what is next. I also DO NOT add an ID to each node. For me one of the great advantages of org-roam-node-find is that
    I can easily move around my nodes. So I want to keep only “entry” points to my info as nodes.
  • I am also finding that many things that I add as TODOs are really SOMEDAY. I am trying to make a clear distinction between a task that needs to be done vs one that I would like to have done. It removes clutter from the agenda.
  • Tags manage/filter info and tasks a lot.

I don’t think my system is perfect, but it has helped me manage my daily activities.

one last thing:

  • you can use [[id:]] to create a graph and manually manage it. Something like this:

    ** TODO subtree to be completed [/]
    - [[id:node1]]
    - [[id:node 2]]

and as you mark them, you get the node completed, and keep going. After all, a dependency graph should be DAG and this model supports that.

3

i kept thinking, and there is a way that one can track dependencies automatically:

  • A hook on save will be needed
  • This hook will find any completed tasks, and see if their node is referenced by another node.
  • scan the location of the reference, if it is of the type - (perhaps completed), marked it as completed (or not) only if needed
  • Scan the header of the node, if it is has a [/] section that is completed, mark it as done.
  • save referencing file

it should not be too hard to implement.