Quote:
Originally Posted by jasong
The difference is that in 1.8, my No Context list is polluted unnecessarily if I don't assign a default context, or all my items get a default context that may not match reality and lead to open loops.
And if I did want to use an *actual* default context for some reason? Then I have to track down the item with the "wrong" default context, which should have a different default context, leading to the "loss" of items by placing them in the wrong context.
I don't tend to use default contexts, because I want to chance to review my items with no context and ensure they're properly categorized. It destroys my workflow to put everything into a default "Review" (or whatever) context, because that means items without a context no longer show up on "No Context", they show up in "Review", and I have to look at possibly dozens of projects and actions, mixed together, only some of which are actually actionable.
Hiding the projects, and using Available instead of Remaining may be a workaround. The inaccurate number of items in a context remains an issue, and disturbs my attempts at "mind like water".
|
I can see how you find this not helpful since you do have to change the workflow.
This is something I used to do when I used LifeBalance, and now I can implement this in OF.
Every project gets the default context that matches most of actions in the project - this way I don't have to enter the context again.
I put filter to things that are available in the context area so that I can only see things I can work on. Even Next action filter should block projects.
The only time projects will show is when it's empty. If a project shows up, I decide to act on the project itself: add more action items; put project on hold and assign a new context (such as Review), mark the project complete, or drop it.
If I add more action items, the project will no longer show in the context view; so, the problem solved.
If I drop the project or complete it, it's done.
Now with the project on hold and with a new context, I can set up the perspective to track these pretty easily.
Let's say I decide to reactivate the project (take it out of hold) and add a new item, but I forgot to change the default context (i.e., it remains as Review). Then the new action items in the project will inherits "Review" as the context, and that's not what I want. However, if I look at what's under Review, I should be able to find the new action item pretty easily. [Right now I believe there is a bug in the context view under remaining that complicates the matter.] Then I can change these items' context easily.
Yes, this does require you to change your workflow, and some people may not like it, and thus, the option to disable this completely (& fixing the bug on counters of course).
However, as some of us have said, I find this feature extremely helpful when using another program (nothing falls through the cracks and I get stuff done earlier than my periodic review would allow); so, I welcome the change in OF.
Now one new feature that might solve your issue might be to have the ability to assign a different contexts to projects/groups themselves that are different than default context (e.g., projects or action groups), that way, we can track these easily in the context view if they show up.
Again, YMMV.