[Chris]

I don't quite see how putting an action on hold would work in the current interface. Some questions.

(1) Would "on hold" actions show up in context mode? If so, under what filter settings? If not, why not?

(2) What happens if an action in a sequential project is put on hold? Do the following actions also go on hold, or not?

(3) If actions can be put on hold, can they also be "dropped"? (Projects can be active, pending, on hold, or dropped.) If not, why not? If so, what does that mean for an action?

[jasong]

I'm perhaps not as clear with my request as I could be. I'm not asking for the ability for an individual action within a normal project be put on hold/dropped/whatever. I'm asking for an individual action within a single action project (aka "singletons") to gain this ability.

If an action is part of a "normal" project (that is, the "This is a list of single actions" checkbox is Off, those actions should be treated as they are treated now. I don't see the value of putting those actions on hold.

However, if an action is part of a "singletons" project (that is, the above checkbox is On, then that action is something you may decide "this is a someday/maybe action" and want to put it on hold.

[Chris]

Actually, I understood that, but I think it's a pretty arbitrary distinction, and confusing for users. I don't think it would be very clear why some actions could be put on hold, and not others. Parallel projects can be lists of singleton actions as well, no? I think it would be pretty funny if the user could put an action on hold because its project had a bucket icon, but couldn't put it on hold because its project had a different icon.

Making subtle distinctions about what settings apply to a given action based on the properties of the buckect holding it seems like a really bad idea to me. What would happen if the user dragged an "on hold" action from a singleton project to a normal project, or unchecked the "single action" checkbox?

It also doesn't answer my questions (1) and (2). Especially (1) seems like a potential problem to me.

[a-one]

I wholeheartedly agree that 'Held" is an important distinct state, and agree that it would be useful to be able to put individual tasks on hold as well as projects (I currently use a Single Tasks project which is set to "On Hold" as a container for single 'held tasks').

However, perhaps a neater solution would be for the calendar drop downs (for all items, whether projects or tasks or task groups) to include a button called "On Hold" - which may internally set the project or task to a start date of say year 3000, but which then displays in the start date field as "On Hold".

That way one cold put any Project, Task or Task Group on hold. In context view they could be filtered out as they are not "available", whilst if reviewing projects they could be visible filtered by "remaining". In Project view, one could filter by 'Projects on Hold' in similar way to how it now works, whilst in Contect view it would be useful to add a filter for "On Hold" in addition to the existing "Available", "Remaining", etc.

[jasong]

Originally Posted by Chris

(1) Would "on hold" actions show up in context mode? If so, under what filter settings? If not, why not?

Why would "on hold" actions show up in context mode? Actions of projects on hold don't. They're not actionable, so they can't be in a context to be acted on.

(2) What happens if an action in a sequential project is put on hold? Do the following actions also go on hold, or not?

I presume this came from a misunderstanding of my suggestion, but since you say that's not the case, I can only say that I don't expect to put actions within a project on hold. If an action within a project goes "on hold", to me that represents the entire project going on hold. I haven't been able to come up with examples where this wouldn't be the case.

Originally Posted by Chris

(3) If actions can be put on hold, can they also be "dropped"? (Projects can be active, pending, on hold, or dropped.) If not, why not? If so, what does that mean for an action?

Certainly. In my mind, a "single action" (not an "action that's part of an extant project") should be treated like a single-action-project. Putting a single action on hold is like putting it in a "someday/maybe" list. Why can't I do that? (Or, why do I have to do something different for a single action than I do for a project?)

I think it's a pretty arbitrary distinction, and confusing for users. I don't think it would be very clear why some actions could be put on hold, and not others

We have this arbitrary distinction now with these "single actions" and "single action projects".

If I capture an action ("build a house"), and, during my weekly review I decide that's a "someday/maybe", I should be able to put it on hold. I shouldn't have to do anything more than that. "Making it a project then putting it on hold" is working around the limitations of the application. It's fine, and it works, but it shouldn't be necessary.

Making subtle distinctions about what settings apply to a given action based on the properties of the buckect holding it seems like a really bad idea to me.

You mean like the subtle distinction between an action in a "regular" project, one in a "singleton" project, and one in an "action group"?

Of course you're right: those arbitrary, subtle, confusing distinctions are a bad idea. I'm suggesting we do something to get rid of them. An action is an action is an action. A project has no meaning except as a container for actions. If I don't have a container for the action, I think of it as a project-with-one-action: itself.

What would happen if the user dragged an "on hold" action from a singleton project to a normal project, or unchecked the "single action" checkbox?

If you drag an "on hold" action from a singleton project to a normal project, it should inherit the project's setting: it's just part of the project now. If the project is active, the action is active; if you aren't ready to do that action in the active project, you can set an appropriate start date. But you've moved the action to an active project, I must assume you plan on either doing that project or marking the project itself as "on hold".

If you want, you can keep the action's previous state, similar to what seems to happen with actions that become action groups and then return to being individual actions. (Go ahead, try it!)

And in my world, there'd be no "single action" checkbox for a project. There'd be four things: folders, next actions, projects and lists. Folders group related things. Next Actions are things I capture because I want to complete/do them. Projects are multiple, related "next actions". Lists are collections of either next actions which don't require one to be done before another; or items in a traditional list (grocery, gifts, etc.).

I do apologize for seeming to harp on this. I respect Ken's position on the difficultly of rethinking this before 1.0 goes GM, and it's certainly not serious enough to prevent me from using OF.

[jasong]

Gah, that was long. Sorry.

[Chris]

Originally Posted by jasong

Why would "on hold" actions show up in context mode? Actions of projects on hold don't. They're not actionable, so they can't be in a context to be acted on.

I'm just asking! :-). Completed actions can be viewed in context mode (well, they used to be!), so why not "on hold" actions? You're suggesting a new state for an action, and I'm asking how that new state would be represented in context mode.

Certainly. In my mind, a "single action" (not an "action that's part of an extant project") should be treated like a single-action-project. Putting a single action on hold is like putting it in a "someday/maybe" list. Why can't I do that? (Or, why do I have to do something different for a single action than I do for a project?)

But you can't actually make actions outside of projects, can you? (Maybe I'm confused here---I tried to make an action outside of a project, but couldn't do it.)

If I capture an action ("build a house"), and, during my weekly review I decide that's a "someday/maybe", I should be able to put it on hold. I shouldn't have to do anything more than that. "Making it a project then putting it on hold" is working around the limitations of the application. It's fine, and it works, but it shouldn't be necessary.

I sympathize; this is exactly how I feel every time I make a fake "action group" to control the flow of logic for actions in my projects.

You mean like the subtle distinction between an action in a "regular" project, one in a "singleton" project, and one in an "action group"?

Of course you're right: those arbitrary, subtle, confusing distinctions are a bad idea. I'm suggesting we do something to get rid of them. An action is an action is an action. A project has no meaning except as a container for actions. If I don't have a container for the action, I think of it as a project-with-one-action: itself.

But OF doesn't actually distinguish between any of these actions, does it? They all have the exact same properties and settings. I thought I was saying what you're saying---all actions should be alike.

If you drag an "on hold" action from a singleton project to a normal project, it should inherit the project's setting: it's just part of the project now. If the project is active, the action is active; if you aren't ready to do that action in the active project, you can set an appropriate start date. But you've moved the action to an active project, I must assume you plan on either doing that project or marking the project itself as "on hold".

This is not obvious. Suppose I create a singleton action, and put it on hold (e.g. "Remodel bathroom"). Then a few weeks later I make a project "Remodel house" and fill it with actions about remodeling the kitchen, den, etc. If I put "Remodel bathroom" inside "Remodel house", it's not obvious that I've actually decided to remodel the bathroom---maybe I don't have enough money. But it's related to the other actions, so it seems reasonable to me that I should be able to put it in the same project and still leave it on hold. I don't see why active projects couldn't have parts that are on hold.

I do apologize for seeming to harp on this. I respect Ken's position on the difficultly of rethinking this before 1.0 goes GM, and it's certainly not serious enough to prevent me from using OF.

I won't complain about you're harping if you don't complain about mine!

BTW, I don't have a problem with allowing single actions outside of projects---that seems very reasonable to me. I just think they should have the same properties that all other actions do. I also don't think "action groups" should exist---they should be subprojects instead (and be able to be placed on hold, and not have contexts, etc.) But that's a different discussion.

[pjb]

Originally Posted by Ken Case

Alternatively, I guess you could be asking for all actions to support the On Hold and Dropped states. I'm actually sympathetic to the idea of adding Dropped as a valid action state, though (as I mentioned above) I'm leaning towards thinking that On Hold is redundant (at least in the data model; the UI might still represent a distant future start date as On Hold).

I could agree with a Dropped Action which is really a skipped step in the Project while I'm apt to just delete it, I'm sure there are those that would like to keep a record of their original intentions.

I do agree that conceptually an On Hold Action is not the same thing as an Action with a future date; maybe it's On Hold until I can set a date and I cannot yet define the next action which will let that date be known (otherwise I could just precede the Action of interest with another Action with a Context of Waiting For). Maybe the Action has a date, but right now that Action has to be off the table until some undefined future time when I may need to know the original due date.

With regards to the rest of the discussion which followed, I find I get less frustrated now than I used to by being very careful about what I call an Action and What I call a project—and my Project list is getting longer and is growing faster now than it used to.

[sprugman]

I have an On Hold context for this situation.

(And I strongly vote against conflating Pending and On Hold, too.)

[Ken Case]

(OK, I've come to my senses: I no longer consider On Hold redundant.)