'On hold' for individual items? (and what does 'Stalled' really mean?)
 

If I am in project view, I can click the inspect (blue circle with white 'i'), click on the '@' "tab" and choose status "On Hold (Waiting)" (' " '). If I am in context view, doing this makes the whole context go on hold, even if I'm inspecting an individual item. Is this expected behaviour or a bug?

What I'm trying to do is "hide" those actions that I don't want to do right now, but _are_ correctly filed into their context, eg. it is an action I want to do in my 'Office', but not right now. Clearly, I could defer them to a specific date in the future, but I'd rather just put them on hold and then look at my 'actions on hold' list when I do a full review (which is what I thought 'Stalled' might mean, but...)

Also, OF's help says "Stalled (projects without any available actions)" (under 'Using the view bar to filter...') but this brings up lots of actions from my projects, so it doesn't seem to mean that at all?

[QUOTE=nate;57425]If I am in project view, I can click the inspect (blue circle with white 'i'), click on the '@' "tab" and choose status "On Hold (Waiting)" (' " '). If I am in context view, doing this makes the whole context go on hold, even if I'm inspecting an individual item. Is this expected behaviour or a bug?
[/quote]
It does the same thing in project view, you just didn't realize it. You've set the entire context to be on hold. Most likely this is [b]not[/b] what you wanted. If you look closely at the inspector window (title bar) when you click on the "@" you've just switched to inspecting the context.
[quote]
What I'm trying to do is "hide" those actions that I don't want to do right now, but _are_ correctly filed into their context, eg. it is an action I want to do in my 'Office', but not right now. Clearly, I could defer them to a specific date in the future, but I'd rather just put them on hold and then look at my 'actions on hold' list when I do a full review (which is what I thought 'Stalled' might mean, but...)
[/quote]
If these actions you want to hide are part of a sequential project, why not just put the project on hold? You won't be doing anything else on that project until you do the action, and putting the project on hold doesn't mess up any state, unlike changing the action's context or start date.
[quote]
Also, OF's help says "Stalled (projects without any available actions)" (under 'Using the view bar to filter...') but this brings up lots of actions from my projects, so it doesn't seem to mean that at all?[/QUOTE]
Have a closer look at your view bar settings. I think you'll find that all of those actions are not actually Available actions, but Remaining (or Due, which is a subset of Remaining) actions. In my experience the Stalled projects filter in project view brings up projects for which there is no Next Action either because the project has no remaining actions (but hasn't been marked complete) or the action which would be the Next Action is unavailable (due to a future start date, or being assigned to a context that is on hold, or in versions prior to 1.6, not having a context assigned).

I've never used the Stalled filter in context view before, and it took a bit of head-scratching to figure out just what it does, because there's some confusing behavior with nested contexts that might be considered a bug, or at least unexpected. It appears that the intent of the Stalled filter in context view is to show all the contexts which don't have any available actions. What threw me off the scent for a while is that I have lots of nested contexts, such as:

Errands
Errands:Grocery Store
Errands:Costco
Errands:Library
Internet
Internet:Macbook

and if Errands:Costco is empty but Errands is not, I'll get a listing of all the actions in Errands that didn't get filed in one of the nested contexts, making it look like the Stalled filter isn't working (how can things be stalled if there's all this work that can be done?) For my part, I think I'll go back to not using the Stalled filter in context view, as it provides little or no apparent value to me, but I would be interested to hear how others make use of it.

For individual actions I want to hide, I give it a start date in the future.
As long as you are looking at available actions and not remaining, the actions will be hidden.

For projects that I am not working on, I place the project on hold. As long as you are filtering by Active projects, you will not see the on hold projects.

The stalled projects filter deems that any project that has actions, but the actions have a start date in the future, then it is stalled. To me this is not correct. If I have actions in the future, my project is not stalled. A stalled project to me is a project or sub-projects that have no children actions to move it forward. I do not currently use the stalled projects filter.

[QUOTE=SpiralOcean;57436]
The stalled projects filter deems that any project that has actions, but the actions have a start date in the future, then it is stalled. To me this is not correct. If I have actions in the future, my project is not stalled. A stalled project to me is a project or sub-projects that have no children actions to move it forward. I do not currently use the stalled projects filter.[/QUOTE]

++

Write a feedback email about it, i'll do the same.

[QUOTE]...nested contexts that might be considered a bug, or at least unexpected. It appears that the intent of the Stalled filter in context view is to show all the contexts which don't have any available actions. What threw me off the scent for a while is that I have lots of nested contexts, such as:

Errands
Errands:Grocery Store
Errands:Costco
Errands:Library
Internet
Internet:Macbook

and if Errands:Costco is empty but Errands is not, I'll get a listing of all the actions in Errands that didn't get filed in one of the nested contexts, making it look like the Stalled filter isn't working (how can things be stalled if there's all this work that can be done?) For my part, I think I'll go back to not using the Stalled filter in context view, as it provides little or no apparent value to me, but I would be interested to hear how others make use of it.[/QUOTE]


This is one of the undesirable aspects of using nested contexts. Question: Other than the apparent organization that it affords, do you find that using nested context offers other advantages as well?

[QUOTE=Chaz2010;60906]This is one of the undesirable aspects of using nested contexts. Question: Other than the apparent organization that it affords, do you find that using nested context offers other advantages as well?[/QUOTE]
It hasn't really been an undesirable aspect for me, because I still haven't been able to figure out what benefit I would get from the stalled filter in context mode, even if it didn't have this behavior! What would I need with a list of contexts in which I didn't have something to do?

More than half of my contexts are nested; I like being able to collapse large chunks of the sidebar when they don't pertain to what I'm doing. I've got about 30 top-level contexts and about 50 nested ones (in a total of 6 groups) so there is a substantial compaction of the sidebar when the nested contexts are closed. If I'm working by myself, I don't need to give much consideration to my Agenda contexts, so I collapse that; if I'm working at home, my Errands contexts are similarly unimportant, so I collapse that. I couldn't do that nearly as conveniently if I didn't use nested contexts.

I don't find that having a lot of contexts makes for appreciable additional overhead. About the only place where I ever have to devote much thought to which context I should assign is with errands involving purchases of items which might be gotten in a variety of different stores. For the small cluster of stores which have their own contexts and occasionally overlap (example: Target, Costco, general grocery stores for an action to buy a carton of milk) I'll file the action in the most usual place, and if I happen to be at such a store, I'll quickly check the errands context for the others to see if there's anything that I could get to possibly eliminate a trip. I used a perspective on the MacBook to do that prior to getting an iPod touch. The perspective was a bit more convenient to use, but the iPod is a lot more convenient to carry!

If I'm in a hurry when assigning contexts, I might just toss something in the top-level context and fix it up when I do my next review. I take a look at what things are in a nested context tree at the top level to see if maybe I should have another nested context.

For me, the ability to slice and dice the workload with sometimes narrowly defined contexts makes it a lot easier to keep productivity up. So many of my actions are from repeating actions/projects or created by templates that even if I have to sit and think for a minute or two about which context to use, the extra cost per action executed is negligible.

[QUOTE=Schlaefer;60897]++

Write a feedback email about it, i'll do the same.[/QUOTE]

Done!