Assignees: projects or contexts?

[rogbar]

I have a bunch of people working for me, each of whom is supposed to get back to me on a number of issues. I have created an item for each of these issues, and assigned that item to the individual. But I'm not sure if the individual's name should be a project or a context.

My first stab at this to make the person a project, and then the context is "Waiting".

Is there a preferred way to do this?

[dschaffner]

I'd say a context for sure, not a project.

The real issue is, would it be a "waiting for" or would in be an "agenda" item for that person. I have both types of context that I use depending in the person. If I have a standing meeting, it's and agenda context, others it's a waiting for context.

[dpvanwormer]

rogbar: I have a similar situation, and I use contexts - not projects.

First, I use GTD principles and many suggestions from David Allen, including the use of "People Agendas" as a context. Under the context of "People Agendas," I have a sub-context for each person I need to deal with regularly - people working for me, my boss, and my peers. Then, under each person's sub-context, I have a sub-sub-context of "Waiting For" which is set to On Hold status. So, in my context side bar it looks like this:
@PeopleAgendas (active status)
.....@Brown (active status)
..........@WaitingFor (on hold status)
.....@Clarke (active status)
..........@WaitingFor (on hold status)

Second, how I use it is two-fold. Items or tasks that I wish to discuss with Brown, for instance, are assigned the "Brown" sub-context. Tasks that I have already assigned or delegated to Brown that I am waiting for him to get back to me on are assigned the "Waiting For" sub-sub-context under "Brown." So when I get a chance to talk with Brown (who actually happens to be my boss), I can focus on the Brown sub-context and see both the items I want to discuss with him plus the items he promised to get back to me on.

For me, it's an excellent way to keep all the items / tasks relative to a specific person gathered together ready for our next meeting. This also allows me to keep all of the person's items separated into those that are currently my responsibility (under "PeopleAgendas:Brown" which is an active context) and those that are the person's responsibility (under "PeopleAgendas:Brown:WaitingFor" which is an on hold context).

[Brian]

I have a context for all the people I work with, but use start dates to move items that I've delegated off of my active list. If I want to check back on the task on Thursday, for example, I set the start date and it goes inactive until then.

Some folks prefer separate agenda and waiting for lists, but it doesn't work as well for me. I prefer to see everything on one list, in case an inactive item spurs some new thought while I'm in the current discussion.

[curiousstranger]

rogbar: I have a similar situation, and I use contexts - not projects.

First, I use GTD principles and many suggestions from David Allen, including the use of "People Agendas" as a context. Under the context of "People Agendas," I have a sub-context for each person I need to deal with regularly - people working for me, my boss, and my peers. Then, under each person's sub-context, I have a sub-sub-context of "Waiting For" which is set to On Hold status. .

I tried doing this for a long time, but the problem I ran into was doing a regular review of all of my Waiting contexts (using the On Hold) filter. Unless I manually selected each Waiting context (which got to be a pain to manage with perspectives), items in the parent Agenda context would show up as well. I'm not sure if this would be considered a bug or not, but it certainly made 'On Hold' sub-contexts not very useful in conjunction with the On Hold filter. I ended up going back to a single Waiting context, but I miss being able to see everything for a particular person, Agenda or Waiting, in one place.

[whpalmer4]

Grouping by context didn't help?

[curiousstranger]

Grouping by context didn't help?

How would it help? I'd still have to manually manage which contexts were open or closed, just as I could by selecting only the Waiting perspectives. Or am I missing something?

[curiousstranger]

Just to clarify, the problem behavior is the display of items in non-On Hold contexts when the context filter is set to On Hold.

[whpalmer4]

But if you're only interested in Waiting:Joe, does it matter what is being shown in Waiting:Bill or Waiting? My suggestion was merely that you'd have everything separated out by context and could thus look at only the context of interest at the moment and more easily ignore the rest, instead of looking at an ungrouped list where you had to inspect each item to see if it had a context of Waiting:Joe...

"No, it didn't help" is a perfectly reasonable answer to my original question, too :-)

Ah -- now that I reread the message to which you were responding, I see that that poster didn't have the structure I was envisioning (a waiting context with subcontexts for each person). My grouping suggestion wouldn't help there, I agree! But you could make a perspective that picked up only those subcontexts, right?

[curiousstranger]

But if you're only interested in Waiting:Joe, does it matter what is being shown in Waiting:Bill or Waiting? My suggestion was merely that you'd have everything separated out by context and could thus look at only the context of interest at the moment and more easily ignore the rest, instead of looking at an ungrouped list where you had to inspect each item to see if it had a context of Waiting:Joe...


I'm referring to an Agenda tree like the earlier poster suggested:

Agenda:
Joe:
Waiting
Bill:
Waiting


The advantages of this structure is that I can easily see everything I need for Bill or Joe, including waiting items.

However, when I do my daily review of my "Waiting" items, I can't see all of them easily without either seeing all the active Agenda items, or manually/perspectively selecting the Waiting only contexts.


Ah -- now that I reread the message to which you were responding, I see that that poster didn't have the structure I was envisioning (a waiting context with subcontexts for each person). My grouping suggestion wouldn't help there, I agree! But you could make a perspective that picked up only those subcontexts, right?

I could and I did, but then whenever I'd add a new Agenda/Waiting person, I'd have to update the perspective. It wasn't the most elegant thing.

I've also tried what you've suggested above:

Waiting:
Bill:
Joe:

But then, I don't have one place to look for my items for Bill or Joe and I'm maintaining two big unwieldy trees. I've since reverted to just using a single Waiting context, but I wish I didn't have to.

My suggested behavior would be for items in non-On Hold parent contexts to not show up when filtering Contexts by On Hold. Is there a downside to that that I'm not thinking of? In what circumstances would you want to see non-On Hold items when filtering by On Hold?

[whpalmer4]

My suggested behavior would be for items in non-On Hold parent contexts to not show up when filtering Contexts by On Hold. Is there a downside to that that I'm not thinking of? In what circumstances would you want to see non-On Hold items when filtering by On Hold?
I don't know if there's a downside, as I haven't thought much about it. I think all of my hierarchical on-hold context use has always been in structures where everything is on hold, so it hasn't been an issue (unlike the merged agenda/waiting case above) and I'm a bit hesitant to give a thumbs up or down. That it is hard to come up with a reason why it shouldn't act the way you propose does suggest that any cases where it would break a workflow are probably uncommon, and more people would be helped than inconvenienced by the proposed change.

Fixes for the problem that involve changing OmniFocus are fine, except that they usually don't happen as quickly as anyone who has a real problem would like. That is why most of my suggestions center around finding a way to work with the tools we have (or can make ourselves with Applescript).

[Brian]

My suggested behavior would be for items in non-On Hold parent contexts to not show up when filtering Contexts by On Hold. Is there a downside to that that I'm not thinking of? In what circumstances would you want to see non-On Hold items when filtering by On Hold?

I'm unsure if that's by design or not: didn't see anything one way or the other in the dev database.

Filed as a feature request: folks that want to see this change appear can email the support ninjas (omnifocus@omnigroup.com) to vote for it. Thanks!

[curiousstranger]

Filed as a feature request: folks that want to see this change appear can email the support ninjas (omnifocus@omnigroup.com) to vote for it. Thanks!

Done! Thanks!