Task is removed from Waiting and moved into Scheduled
Environment
Windows 10, Everdo 0.14.1
Additional comments
A Waiting item can have a either/both a start and a due date although commonly just a due date by which time we want to ask someone âhey, what about X?â
I use flagged/starred items with start/defer dates regularly to have things automatically brought to my attention. So I may want to be able to review all my Waiting Forâs but also want to have this particular Waiting For, which I starred, automatically reappear in my focus late on this or that date
I thought that the Due date would fix the issue but then if the item is starred, it will still appear on the focus list before I want to work on it; so being able to set a Start date for a waiting for would make sense
By design, Scheduled and Waiting for states are mutually exclusive. This is not a coincidence - those states correspond to GTD concepts. An action can be either scheduled, or delegated, but not both at the same time.
If what you are trying to do is to review some of your Waiting items from time to time, the way to do it is during a daily review process. You can setup something simple like this and it should work: review checklist setup example
Or just schedule a different recurring task to review some of your waiting actions.
Hereâs an example on how I use the combination in Omnifocus:
Iâm waiting on results from my doctor. I know it usually takes about a month so I set a Waiting For with a Defer/Start date of month out. The Waiting For is flagged so one month from now a @WAITINGFOR pops up on my flagges/focus list and I think âhey, letâs seeâ
Think of it as the automation of (waiting for) tasks
I imagined something like that, but I think allowing this goes against the concept of Waiting
The way I see it:
If the task is truly delegated (which is why itâs in waiting) , then you shouldnât have to check on it. Instead, you should get notified of itâs completion. You still have the list of all such tasks in the âWaitingâ list so that you can follow up yourself, but thatâs an exception.
As an example from my own experience, here are the things I typically have in Waiting, none of which require action on my part.
someone has to reply to my email before I can proceed
a report on which I can act
sometimes, medical test results
I also review the waiting list daily, so if I suspect something is taking too long, then I will follow up.
If thereâs a task that requires me to check something manually, then it probably belongs to âScheduledâ as a repeating task.
Thatâs the beauty: I donât have to with the setup I outlined.
Maybe âscheduledâ only comes into the discussion because of the terminology we use in the program. For me itâs a deferred date in Omnifocus.
Even without agreeing with the concept of my setup, hereâs why the deferred date on a waiting task works against me: if I make it a due task, and already focus/star the item so it will pop up in my focus list when I want it to, the waiting for will be listed there all the time. Compare with Omnifocus where I can set âdue by mondayâ, âdefer until sundayâ or something like that; the @WAITINGFOR will be hidden in my flagged task lists etc until it is time to come back.
If I understand you correctly, the thing youâre after can be done in Everdo by scheduling (deferring) a task and specifying a due date, but without changing the status/list to waiting. This way it will not appear in waiting though, but maybe it shouldnât because of the nature of the task?
I guess Iâm just trying to understand how much of a problem this is (not being able to schedule a waiting for task).
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?â
In this example, why do you need to have this task in Wating? Why canât it just be scheduled: âAsk Andrei why the feature still not done?â Then it will truly be off your mind and it will pop up when you need it.
This is because âWaiting Forâ is a state, not an item type. At this moment, you canât schedule Waiting For for the same reason as you canât schedule âTrashâ, âInboxâ and everything else - those are treated as mutually-exclusive states everywhere in the program.
Itâs not that simple. The way I see it, the gain is that youâll be able to do something that is already possible (in very low-friction way) with just âScheduledâ. But you want it done in a way that is bit more familiar/logical to you. Which is subjective, as this discussion indicates.
The downside is effort and code complexity. Each seemingly small detail like this is expensive in the long run. And this one really is far from small. It will takes time to think through and implement, it will cause some regression defects, It will pull effort from other features. Which is why I must be convinced itâs necessary, not just nice/familiar for a sub-set of users.
Iâll try to quantify my feature requests better in the future because thatâs specifically something I want to help to try to avoid; running after ever feature request. Software reality that when you like 5 features, you can have all of them at any time â but in 5 different programs. Or you can have 3 perfectly done in the same program, 1 so-so implemented, and 1 is the opposite of what you wanted
I like flexibility and I like scheduling but if I need to quantify this, itâs a ânice to haveâ but not âneed to haveâ, and using Scheduled instead of Waiting For would work for me.
