I am jumping into this a little late, but I have a very useful application of Contexts that almost begs to allow more than one to be assigned to a given task. It also takes advantage of the hierarchical structure of Contexts in OmniFocus.
I have tasks organized in a way that’s consistent with the way I think about and address them. That’s what I use projects, folders, and multi-step (serial or parallel) task structures to accomplish. The majority of my OmniFocus tasks are things that I need to do, but I also use them sometimes to track things I’ve asked (or need) others to to.
In addition to conventional GTD-esque contexts, I have also defined organizational contexts: “company” at the top-level, “division” or “group” at the next level, and often also a “project” as a third level. Those are the “branches” of the tree. The “leaves” are all people’s names.
When I create a task or sub-task representing what someone else needs to do (or with whom I’ll need to get it done), I’ll assign them as the context. When I do that, it’s not just their name that identifies them, but (it can also be) that individual’s “location” within the context hierarchy that is based on the role they’re playing.
The same person can exist in more than one “context path”: there may be someone who is a member of a shared-services group within the company, for example, but they may have been assigned to work for (or on) several projects being managed by different divisions. I may be working with the same person, for example, in completely different projects.
This also allows a very neat way to track delegation of tasks through organizational units. For example, we have a “technical services” group within the company. Within that are the network security people, operations, help desk, and so on. If one of my subtasks is to get them to fix a problem, I can initially assign the group that’s supposed to handle it as its context. Then, when someone is assigned to work on my problem, I can change the context to be more specific such as the individual whom I need to contact to track its completion.
These are things that cannot be done with simple, one-dimensional classifications like tags. (They also cannot be handled effectively with links to address book entries.) I don’t need to know who their boss is in the company nor which status meetings they attend. What’s important in managing people-as-“contexts” is the capacity in which they are relevant to the task, not what their organizational relationship is to me as a fellow employee.
Just as visiting a project lets you see all of the tasks and sub-tasks, I can also visit the “context” for a workgroup to see all of the tasks for which I have them in a resource or co-worker relationship. Using my example, I can see all of the outstanding requests that I’ve made against anyone in the “technical service” group, or I can view successively more specific contexts to narrow things down.
So what does the inability to assign more than one context do to me? It forces me to unnaturally relate a task to a single organization or individual when it often makes more sense to relate it to two or more entities in the tree of contexts.
This cannot be done with tags, and the way I am using it does not in any way conflict with or add complexity to the other, more conventional (e.g. GTD) use for contexts. In fact, I have a “@Waiting” context that should also apply to these tasks!
Now, if only I could link to the address book entry from a Context…
