I’ve become a big fan of hierarchical todo-list managers.  It’s great to go down from “All of Life” through Roles to Goals to Projects to Tasks to Next Actions.  I don’t know if it helps me be more productive, but it certainly feels good to think that everything’s connected somehow.

Except some things are not just tree-connected.  They’re graph-connected.

What’s the difference?  A graph can have several “ancestors” (maybe better to call them “predecessors”) for each node.  So a task like “send article to Joe” can belong to “cultivate relationship with Joe” and “send article to tech visionary friends.”

An example of graph structure which most GTD-oriented software supports is “contexts” vs. “projects”.  My project might be to finish the sprinkler controller, but different parts of that project will take place in different contexts: Workshop, Internet, Computer, InMyHead.  Contexts are usually implemented as labels.

One graph-structured problem I’m wrestling with now is the distinction between a project and an event.

I might have a project, say, to improve my friendships with several friends.  And I may have an event where I get together for drinks with some or all of them.

With a hierarchical PIM and contexts, I have a couple of choices about how to implement this:

1. The Event could own the Projects.  In this case, “Get together for drinks” owns all of the people I’m going to have drinks with.  Problem: it’s inelegant, and it’s transient.  Once the event is over, I have to stick the various friends someplace else.  One would think that the friendships were the more important or less transient or more durable thing and should therefore go above the event in the hierarchy, but there’s no easy way to get a number of parents in a hierarchy to own (or share ownership of) a child node.
2. The Event could be a context, a label.  Probably a better solution, in that a context is sort of like an event — it’s a physical or logical place where certain tasks can be done — but I’ve already overloaded contexts in my PIM and it’s starting to break down.
3. The PIM I use now, MLO, allows a node to own an unrelated node elsewhere in the hierarchy, but these relationships are kind of hidden in the software (maybe an afterthought for the developers) and hard to manage.  One wants the graph relationships to be first-class citizens within the software.

Any thoughts?