There are some contexts that are “on hold”. Let’s say, there is a city we sometimes go, which has its own context, for the things we want to do when we are there. Since we are not there at this time, its context is on hold. There is no need for us to review the items that will only be of use once we are there. When we get there, we are going to make that context active, and see the items.
Since there is an option for excluding on hold projects from Review, why can’t we exclude projects with the only available action or actions set to an on hold context? This can be automated with an option. This doesn’t need me to mark the same irrelevant actions as reviewed over and over again. I already organise them in a way that doesn’t need me to deal with them again until I get to that context.
The review mode is meant to review projects and not contexts. An “On Hold” context will be hidden when you have a perspective set to show “Available” or “First Available”.
If you don’t want to review a project as often, use the inspector panel to change the review cycle (every 60 days or longer). You can also set the review date to a further time in the future so you won’t see the project show up.
There are time when I would like to review projects even when I’m not at that context. I’m not at Home Depot all the time. But I would like to see my Home Depot contexts during a typical review process.
I was talking about projects and actions, not contexts.
I’m sure the way it is has its uses. On the other hand, excluding and including on hold projects both have their options available, as they have their uses as well. So why would my need to exclude projects that have their all or only actions set for on hold contexts, should be ignored?
In your use, such items may be needed to be reviewed, whether their contexts are relevant or not. In my use, they are not needed to be reviewed, because I set them that way. Even if I needed to review them, I could do so by checking or unchecking a box, just like doing so for including or excluding on hold projects, which is already implemented.
Therefore, for my use, the efficient way is not to set the review cycles for each and every one of such items to a greater value. The efficient way for my use, is to be able to simply check a box, and exclude all projects that have all their actions set for on hold contexts, or their first actions set for on hold contexts, if they are sequential.
Actually, especially on hold projects need to appear in the review, there is a good chance that this is the only view were You are getting a heads-up on it still existing. Therefore, on hold/active/completed/dropped are one level of distinguishing and review cycles are a completely independent one. The interconnection You are suggesting is adding a level of complexity, because suddenly appearance in the reviews would not, as it is, solely be a matter of time. That would make oversight more complex and therefore less reliable…
Unlike the processing of tasks, reviewing them should not depend on project or context status at all, giving You the option to step out of the cycle and reconsider projects that were idle for a while (this while is individually determined by You).
I understand the value of including everything on the review. But I still don’t see why we shouldn’t have an option to focus on things other than the ones we put on hold, for when we need to.
We already have an option to exclude on hold projects. If I ever need to use that option, I might as well like to see the review cleaned of everything on hold, and I actually do.
I would be totally against this (levels of complexity as already stated) plus how hard is it really to just click reviewed if you know nothing in it has changed? It’s a second or two that’s all.
If you really believe you need those couple of seconds you can always set the review period for once a year which effectively excludes it.
If time is tight then reviewing “live” projects only could be beneficial. As could a dedicated review of “on hold” projects (kill, revive or extend the review period)
If it is an option then it wouldn’t affect “normal” workflow.
If you want something like this then email omni - that is their preferred way of tracking demand/popularity.
In the meantime I suspect that extending the review date to six months to stop them appearing on your regular reviews would deal with ‘hiding’ them and setting a tag and creating a perspective around that tag would enable you to find them and individually mark them reviewed for when you do a periodic “should these be active or not” review.
