[whpalmer4]

Originally Posted by Robbie1702

It would be brilliant though, if some real "blackbelts" in GTD using Omnifocus could publish their entire layouts (routines, templates, project folders, someday maybe lists, due dates, start dates, repeating due dates, review strategies, shopping lists, single action lists, contexts, ways they formulate actions etc... EVERYTHING) onto a page for all "non-blackbelts" to view so they can learn from it. I know there is no one single way of organising things, but some excellent examples would surely be helpful to sooooo many people.

A lot of us have posted this sort of thing, though rarely all in one place, and some of it is admittedly difficult to dig up even if you sort of remember the post! You might find it productive to just do an advanced search on the forum for posts by Toadling, Curt.Clifton, and Ken Case to name a few that have taught me quite a bit. Some of the more contentious discussions that rattle on for many pages have quite a bit of good material -- I'm thinking of threads on multiple contexts, tagging, and oh, yeah, how to use waiting contexts :-)

With regards to the script - I don't see why it can't be built into OF if it's so useful...

Ah, but someone just retooled the script for a very different purpose (take an action and turn it into an email to someone, complete with attachments) and that wouldn't necessarily have been possible if this was a built-in feature. Built-in features are nice, but the ability to build your own features is often even nicer, especially if your desired features depart from the mainstream view! And given that Omni can only devote a small amount of engineering effort (relative to the size of the union of everyone's wish list), it's better that they spend the effort implementing features that can't feasibly be done by 3rd parties.

But besides, until someone can prove me wrong: waiting is still NO CONTEXT in my books - it's a state of an action (like "on hold"). A context is an ESSENTIAL PHYSICAL REQUIREMENT I NEED to complete an action (Tool, person etc.). If the person I need to see to complete the task is "Peter" (i.e. the context), why would I EVER need to change the context to anything else - simply because I'm waiting for him "Peter" - and not him "Peter:Waiting". I simply need to see "Peter". The thing is - if I am with Peter and I click on the context "Peter" (on my iPhone or Mac) to see what I need to get done in his presence, I will fail to see the tasks that are in "Waiting:Peter". Hence there should only be ONE context (i.e. "Peter) - PLUS the option to right click a little status button (as suggested in the feature request) indicating that I'm waiting for him to do something.

You do yourself a disservice by sticking to the notion of a context being an essential physical requirement. It's actually a much more flexible tool if you lift that restriction and think of it as a way of grouping or subdividing your tasks. Ken's post gives some nice examples of what might be termed virtual contexts, and read the rest of the thread for more examples (there's another very descriptive one from him a few posts earlier).

I agree that having multiple contexts where your interactions with Peter might be filed can be a cause for trouble if checking them all isn't second nature. However, OmniFocus doesn't force you to use such a structure if it doesn't provide you with sufficient benefit. You could equally well just have put both the "send Peter email requesting quarterly report" and the "receive quarterly report from Peter" actions in your Agenda : Peter context, and not have a Waiting for : Peter context at all. What you lose by doing that is the ability to have a context you can look at to see all the things you are waiting for, but maybe that isn't of much utility to you. You could also come up with a standardized fashion of noting such actions, like prefacing the action name with "Waiting For:" so that you could do a search to pull them all out if you needed a list. Perspectives retain a search string present when the perspective is captured, so you can even set it up as a toolbar button.

Examples are good, and I agree it would be very helpful to new users and seasoned veterans alike to be able to see detailed examples of different working practices (indeed, seeing how others approach the tools is one of the primary attractions of the forums for me). I strongly believe, however, that there is significant value in experimenting a bit in order to make an informed choice. And even after you settle on a choice, look back after 3 or 6 months and think about what has worked well and what creates friction. There's no universal truth that says the correct approach for you now should always be the correct approach.