That’s a very valid workaround although I then miss all the fun and efficiency of the true Waiting For list, something where even in Omnifocus you have to jump through hoops to create one.
Here’s how I look at the imposed limitation:
- I can schedule Projects
- I can schedule Tasks
- I can even schedule Notes!
- …but I’m not allowed to schedule Waiting For’s…
Quantifying how much of a problem it is is always challenging, especially as the first users you’ll be getting are power users and geeks: we can come up with workarounds, make due with everything, etc.
In my own setup in Omnifocus, this is how I handle it. I ask you for a feature. You respond and say “that will come out in #Q2 of 2018”. I create a Waiting For with a Defer/Start Date of, say, mid May 2018. I flag/star that Waiting For. It’s now totally off my mind because I know that @WaitingFor will popup, automatically, mid May. If it tempts me to review my @WaitingFor’s manually, I can.
The cognitive load is gone: I can rely on my system to show me the @WaitingFor or Someday/Maybe when I need – or can see it in the appropriate list when I want.
To advocate my case more: I think it’s the expected behavior that when you assign a task a status or list (like Waiting or Someday) and you set a start date, it doesn’t suddenly all by itself change the status of the task I just assigned to it. Why would I have the option on the form if using it undoes what I’m trying to do?
Allowing Scheduling on Waiting For and Someday allows for all use cases; limiting it does not.
- Scheduling allowed: power users or people who don’t want to stick to GTD’s rules 100% can use the system the way they want. Regular users never think about it twice; click Waiting and that’s it.
- Scheduling forbidden: power users are forced to not use the system the way they want. Regular users never think about it twice, click Waiting and that’s it.
It adheres to the core values of the program:
- low friction: instead of finding an imposed limitation, it just works. I won’t be the only OF user thinking “hey…why does this not work?”
- no required fields: enforcing no scheduling on waiting and someday is a form of requiring fields
So to sum up:
- allowing scheduling on waiting & someday without removing it from the list just assigned to does exactly what the user just tried doing
- keeps it as simple as possible (no surprises) without making the program more complicated while requiring workarounds does
- adheres to the core values of low friction, no required fields
- allows for all use case scenarios without muddling one or the other
It’s a win on all fronts. It’s a “why not?” instead of a “why?”