[Chris]

I just sent this feedback to Omni, thought I would post here as well.

Uncompleted action groups don't block subsequent actions in context mode, but if an action group is repeating, then if it's uncompleted it DOES block the appearance of the next cycle of actions in context mode, even if all the actions in the group are completed.

I noticed this because I have a "Weekly Preparation" action group, and I noticed that next week's actions weren't showing up in context mode. That's because, while I had completed all the actions in this week's preparation, I hadn't gone back into Planning mode and checked the action group itself as complete. This is something that I don't want to have to do! It leads to a system I can't trust, because if I forget to go back into planning mode and check that little box by the group, my actions for next week won't show up in context mode.

So, I would either like (a) the option to have action groups autocomplete if all the actions in the group are completed or (b) not have uncompleted repeating groups block the appearance of the next repetition of that group.

This is something that really needs to be handled better by OF.

[kaebot]

I'm sorry for the trouble here. As you know, if there is an action group that repeats, it will create a new one upon completion immediately after itself in the list. In a sequential project, this can be troublesome. I've added this to our bug database.

In the mean time, as a workaround, does creating a parallel project with two sequential action groups unblock those actions? To be clearer, you'd have your weekly repeat action group (for these I add a start date so that they're unavailable upon completion for the week) and then a second action group that contains everything else, also set to sequential.

The problem with this is that the first action from the second group will be shown, however it's no longer blocked and if you know when you do weekly preparation, you could set a start date on the second group or first action of the second group that coincides with the completion of the weekly preparation group. I understand it's not ideal, but it's important not to block those actions. Sorry!

[Chris]

I'm a little confused by your response. The problem isn't that the action group blocks other things, it's that it blocks the next iteration of itself. My project is already parallel. I want the next cycle of actions to appear in context mode, as soon as all the actions on the current cycle are complete, even if the action group itself has not been marked complete. Does that make sense?

To put it another way, I don't want the last action of the group to have to be something like "Don't forget to go back into planning mode and check off "Weekly Preparation" as complete."

[kaebot]

Sorry for misunderstanding! I see what you mean and I've written up this issue. Sorry about that!

In the mean time, I know it's not ideal, but your proposal for a workaround is probably the best solution. You might instead add "(last)" or the equivalent to the last item in the group so that you know that it's the end of that group and can then reveal it in Planning mode and complete the group. Again, very sorry for the trouble.

[jasong]

Chris, wouldn't allowing "the next cycle of actions to appear", "even if the action group itself has not been marked complete" defeat the purpose of next-actions?

I understand your need, and I recognize it as valuable, I just don't want to see OF add stuff that makes it possible to leave open loops.

I don't think OF does very well with pre-planned, well-defined projects. Heck, I don't think GTD does either, but that's not really the point of GTD.

[Chris]

I don't understand what loop would be left open given my suggestion. All the actions in the group are done. If there's an undone action, why doesn't it appear in context mode?

Omni already recognizes this, because "uncompleted" action groups don't block subsequent actions in sequential projects. All I'm saying is that repeating action groups should behave the exact same way. That they don't is a bug, imo.

I don't want to see OF be a system I can't trust because there are "actions" that need to be "completed" even though they never appear in context mode and then have these "actions" block the appearance of other actions that DO need to be completed.

As for the point of GTD, isn't the point to put everything in your trusted system, so that you don't have to carry it around in your head? That's exactly what I'm trying to do, and what OF is preventing me from doing. (Or forcing me to put in put in pseudo "Don't forget" actions to work around its limitations.)

[jasong]

Hm. I think the bug here may be that in a project like the following:

* Project (sequential)
* Action Group A
** Action A1
** Action A2
** Action A3

* Action Group B
** Action B1
** Action B2
** Action B3

when Actions A1-3 of Group A are done, I immediately see Action B1 of Group B; in fact, until I've had a chance to confirm that Group A has no more actions (and either add more actions or mark it as complete), nothing from Group B should be showing up at all.

The repeating issue, where you have to return to project mode and mark the action group as “done” strikes me as the correct behavior: the project can't repeat until it's done, and OF can't be sure it's done until you've reviewed it and said it's done.

I understand and recognize that for “pre-planned projects“, with action items which never change, this is a pain.

The review portion of GTD is an integral part of the system, and anything which cirumvents that, leads, in my estimation, to open loops, or the uncertainty that I've actually completed things I'm supposed to have completed.

Pre-planned projects may not have this open loop concern.

Auto-marking an action group as complete is an option I know many are asking for; if it shows up, I hope it's something you turn on, and isn't on by default (and is a per-action group preference, rather than a global one).

[curt.clifton]

I think a setting like "this action group auto-completes" would be perfect for handling repeating action groups. It seems like in most cases a repeating action group would be fully planned, so turning on an auto-complete option for the group wouldn't result in open loops.

[Chris]

Jason,

I think our different views result from the fact that we seem to use action groups differently. You want to use them as de facto subprojects, while I use them strictly as flow-of-control structures for action dependencies. I'm not saying that one or the other is correct, or better, but I think it illustrates some of the awkwardness in the current design of OF. Action groups currently inhabit this funny dual space where they are not truly actions (context mode objects), nor are they truly projects (planning mode objects), they are some of each. (My earlier suggestion, in the "How action groups SHOULD work" thread was to turn them completely into action-like objects; clearly people who want them to be project-like didn't like that!) I'm not sure there is a real resolution to this dilemma in the current paradigm, though as you and Curt mention, having the option to auto-complete action groups is one possibility, and I have asked for that myself.

But even in the paradigm I am asking for, you could still avoid open loops by adding a "Make sure there are no open loops" action to the end of each of your action groups :-).

[jasong]

I couldn't agree with you more: action groups are neither fish nor fowl, and therefore leaves both sides unhappy.

I've filed official feedback w/OG to fix what I describe as a bug and to introduce a per-action-group “mark this as complete when all actions are complete” preference. I believe that's the best compromise.