View Single Post
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.