[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.

[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.

[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).

[curiousstranger]

Originally Posted by 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. .

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]

Originally Posted by whpalmer4

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.