Due Date & Waiting For
 

I'm at a bit of loss as to how due dates & waiting for status are supposed to work.

I use 'waiting for' often when delegating tasks or waiting for answers from people. When I put the action in waiting for status, I usually put a due date & current date on it so that if I haven't heard from that person by then I'll know to send them a follow-up ("I sent you X on date Y, etc.).

I'm still getting my head around OF, but it appears that actions in the waiting for state don't show up in the due perspective nor the the badge count.

In fact the only reason I noticed this problem was during today's iPhone sync (it had been about 3-4 days since I synced) and there were suddenly 14 due soon actions!

So two questions really:
[LIST][*]Is my waiting-for-with-due-date the right way to use these two features and[*]What's the best way to view all the items that I've got outstanding with other people (and thus in a 'waiting for' context)[/LIST]
Regards,
- Steve

There are two main schools of thought on this, with the key point being whether or not you make your Waiting context one that is On Hold or not (the one in the canned database that Omni ships is On Hold, as you've discovered). Many experienced practitioners choose to make the Waiting context an ordinary one, and simply don't check the item off until whatever is being waited for occurs. That will block subsequent actions in a sequential group, and illustrate what needs to happen before the project can move forward.

I've always used the default "waiting contexts should be on hold" approach, but as I write this, I'm unable to explain why :-) I guess I'll have to go look at an old post on the topic, or try it the other way for a while. The only thing that comes to mind is that marking the context On Hold results in different styling of the actions so it is maybe a bit easier to spot that there's something I'm waiting for and can't necessarily immediately proceed -- just as if that action had a future start date. I don't think either approach is wrong, just a matter of what works best for you. You may find that your preferred approach changes after you've got more experience, too.

If you put such things in a specific context or set of contexts, you can make yourself a perspective that just shows those contexts for a quick view of things you are waiting on from others.

Ah, just rediscovered one more difference between the two. If you do put your waiting contexts on hold, you can use the Stalled filter to show you the projects that are stalled waiting for such actions (along with any other projects that simply don't have an available next action). If you make the waiting for contexts available, you can't do this, because OmniFocus won't consider the projects stalled.

[QUOTE=whpalmer4;72477]There are two main schools of thought on this, with the key point being whether or not you make your Waiting context one that is On Hold or not (the one in the canned database that Omni ships is On Hold, as you've discovered). Many experienced practitioners choose to make the Waiting context an ordinary one, and simply don't check the item off until whatever is being waited for occurs. That will block subsequent actions in a sequential group, and illustrate what needs to happen before the project can move forward.[/QUOTE]

That's exactly what I need. Will try turning off the on-hold status of the canned database and see if that helps.

This seems to be a case of hybrid context. From [I]my[/I] perspective it is on hold; there's nothing that I can personally do to move it forward. On the other hand I'm not going to let someone indefinitely stall a project, so at some point I'll either do the task myself (if possible) or delegate it to someone else, so from that viewpoint I can still move the project forward if enough waiting-for due dates expire.

- Steve