I don’t remember this being an issue in the past. Then again, maybe I’m just nuts.
I’m trying to build a better “waiting for” perspective. The problem is that in order for it to work I must show remaining actions. But by doing so it shows all actions with the waiting tag, even those that aren’t live yet.
Suppose I create a project called EAT TACOS. It is a serial project.
Find taco truck on Yelp (mac)
Drive to taco truck (errand)
Order 100 tacos (quick action)
Receive 100 tacos (waiting)
Task 4 is tagged (waiting) and is something I’m waiting for. I was funny with the tacos, but it could be receive payment for invoice, or receive response to proposal, etc.
The (waiting tags) are hidden, which is nice, and I run a waiting perspective for years now. I was looking at it tonight and noticed that tasks not truly available (in that I’ve done the preceding tasks and am actually waiting for something) are showing up. Task 4 above would show up in my perspective, which severely limits the usefulness of the perspective and the tag.
It would be better to create a different tag, add “do not display” to alll perspectives, and display only active tasks with said new tag in a makeshift true waiting perspective. If that makes sense.
You’re not nuts. What’s actually happening is that you’re trying to create a logical paradox, and like all logical paradoxes, you’re finding that it’s logically impossible.
In the OF world, an oustanding task is either available, or it’s unavailable. You have, naturally enough, set your waiting-for tasks to be unavailable, because there’s nothing you can do with them other than wait.
But then you say:
The fact that you’re talking about unavailable tasks which are “truly available” points to what’s going on, here. To show only those waiting-fors which don’t have tasks before them in a serial project, here’s what you’re actually asking the perspective to do:
Show me a list of all unavailable tasks except those which aren’t unavailable yet.
If a task is not unavailable, then it’s available. But you’ve already said they’re all not available, by giving them waiting-for tags. So you’re trying to exclude a list of tasks which are simultaneously both available and unavailable, and since this is inherently contradictory, you’re finding that you’re not able to do it.
OF contains a number of features (e.g. next action only, sequential projects) that take a set of available tasks and temporarily make some of them appear to be unavailable, so that you can avoid seeing them in certain contexts. But there is no such feature set for unavailable tasks, because they’re all unavailable by definition to begin with, so they never need any additional filtering out under this model.
The only way you’re likely to be able to do what you want is to stop calling waiting-for tasks unavailable, and maybe set your perspectives up to just exclude tasks tagged waiting-for in all your normal perspectives, and to exclude everything else in your waiting-for perspective. Your other option is to just not mark tasks as waiting-for in your system until you’re actually waiting for them.
I believe I had a similar struggle with the concept when I first got into OF. It might help to remember that these waiting-for tasks are, in fact, available - just not to you.
Other than the above solution, I also use flags, and sparingly due dates, to help surface the priority waiting tasks.
This is precisely why I’ve been arguing against waiting-for contexts or lists for years now. Why clutter my attention with stuff I can’t do anything about yet? Instead, for each item I’m waiting for, I create a deferred task to follow up on whatever it is in case it doesn’t show up as expected (in this case maybe ❏ Ask taco truck guy why my tacos are taking so long, with a start time 30 minutes after placing my order).
If the thing I’m waiting for arrives as expected, I can handle it like any other inbox item, and dismissing the unneeded follow-up action when it becomes available is just a matter of hitting the spacebar once. If the thing I’m waiting for doesn’t show up, at least it’s been off my mind until such time as I need to take action on it.
I think the simplicity of your example is actually confusing the issue here.
For something this simple, a Waiting For tag would be overkill. A single deferred & repeating action to confirm delivery in your EAT TACOS project would be enough. You don’t want to create a new tag every time you want to make sure that something which was supposed to get done by someone else actually got done.
For something more complicated, where you will do several things in several projects with your tacos once you get them, what you are waiting for is the tacos themselves, and you do actually want to keep track of that dependency regardless of whether you’ve placed your order yet or not.
One relevant issue is how you remember to check up on your Waiting For tags. I do that through actions, one for each Waiting For tag. Sometimes those actions are things I need to do myself and sometimes they are deferred repeating actions to check up on things out of my control. In your example the steps of the EAT TACOS project would act as my reminder. Action #4 would be something like “confirm taco delivery & activate tag”, and it would be deferred and repeating.
