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.
