[curt.clifton]

Originally Posted by brooce

Nope! Add a new un-done task, presto! The project is un-done again.

Right, but how do you differentiate between projects that are really done and those where you have to think of a next action? Once I decide that a project is done, I don't want to see it again (unless I'm reviewing completed projects to celebrate my successes). Do you seriously intend to review every one of your completed projects to see if it is really done or if it actually needs a next action? That's just not reasonable, especially in a system like OmniFocus that retains a complete history.

Originally Posted by brooce

One would NEVER want the state wherein all subprojects & tasks are done, but the project remains undone. That's the only behavior 'enabled' by having projects maintain their own done-ness, rather than adopting.

I agree in principle. But there is a huge difference between every subproject and task entered in the program being done and every subproject and task needed being done. I sometimes want the program to specifically call out the state where the entered tasks are done but I haven't marked the project as done. In this state my next action is "Determine the Next Action for this project".

I also sometimes want the behavior that you are requesting. For example, for many of my projects I actually do know every step. So when I complete the last task, the project should be marked as done.

So, I need the functionality I'm asking for. I would also like the functionality that you're asking for. I think a single bit of additional data on each project and sub-project would accommodate both of us. If the bit is preset based on a preference, then you can happily ignore the bit.

If only one of the functionalities is included, then we need to consider how the other would be simulated.

If the auto-completion functionality is included, then I need to explicitly create a last action "Determine the Next Action for this project" whenever I create a project where I don't know all the actions. This is extra work that interferes with the flow of project planning, that I could accidentally forget to do, and that would not be detected automatically by the system. Thus, this decreases my faith in the system and interupts my "mind like water".

On the other hand, if auto-completion is not included, then when I check off the last action on a project I'm automatically reminded to determine the next action for the project. If the project is really done I get another little endorphin rush by making one last check-mark. If the project is not done, then my trusted system reminds me to think of the next action.

In summary, I strongly advocate for including both functionalities. But if a choice needs to be made, then the program should choose the one that minimizes the chance of information loss.

[Craig]

This is an interesting thread and I appreciate the thought put into it - I think it is a dilemma.

The recent posts seem to be addressing this as an either-or setting. I hope brianogilvie's post about how Life Balance works (about six up in this thread) doesn't get lost in the shuffle - it might be the most likely way to satisfy the most users.

[Weasel]

Originally Posted by curt.clifton

I agree in principle. But there is a huge difference between every subproject and task entered in the program being done and every subproject and task needed being done. I sometimes want the program to specifically call out the state where the entered tasks are done but I haven't marked the project as done. In this state my next action is "Determine the Next Action for this project".

I also sometimes want the behavior that you are requesting. For example, for many of my projects I actually do know every step. So when I complete the last task, the project should be marked as done.

So, I need the functionality I'm asking for. I would also like the functionality that you're asking for. I think a single bit of additional data on each project and sub-project would accommodate both of us. If the bit is preset based on a preference, then you can happily ignore the bit.

If only one of the functionalities is included, then we need to consider how the other would be simulated.

If the auto-completion functionality is included, then I need to explicitly create a last action "Determine the Next Action for this project" whenever I create a project where I don't know all the actions. This is extra work that interferes with the flow of project planning, that I could accidentally forget to do, and that would not be detected automatically by the system. Thus, this decreases my faith in the system and interupts my "mind like water".

On the other hand, if auto-completion is not included, then when I check off the last action on a project I'm automatically reminded to determine the next action for the project. If the project is really done I get another little endorphin rush by making one last check-mark. If the project is not done, then my trusted system reminds me to think of the next action.

In summary, I strongly advocate for including both functionalities. But if a choice needs to be made, then the program should choose the one that minimizes the chance of information loss.

This sounds quite reasonable to me, I would like to have the option to set this parameter on a project-by-project base. And maybe have an option to 'apply to all subprojects'?

I have a bunch of 'projects' that never end, e.g. 'books to read', not that this project is ever going to be out of tasks, but in case that occurs I'd not like it to disappear as done.

[brooce]

> Right, but how do you differentiate between projects that are really done and those where you have to think of a next action?

You don't; you have a computer to think for you!

You think your project is done, and you move on. One sad day, you realize there's another task (or even sub-project) to be handled. Add it, and the containing project would instantly be reactivated.

> Once I decide that a project is done, I don't want to see it again

Agreed! But, if you realize you have another task to complete before the project is done, you'll probably want it to reactivate.

> In this state my next action is "Determine the Next Action for this project".

Good point.

[johnrover]

Originally Posted by Athanasius

I agree. It is confusing.

Yes. Absolutely so. This thread is practically identical to this one:
http://forums.omnigroup.com/showthread.php?t=3642


I can't quite see what the advantage of making distinctions between projects, task/action groups, task/actions, and sub-tasks/actions. Everything would be much easier and simpler if they were just "objects" with a parent/child structure.

Every object should have every property start / due / context(s) / state / repeat, etc. Every object should have a checkbox. New child objects should inherit properties from parent objects automatically. If the properties of a parent object are changed, the user should have an option to "propagate" that change down to the child objects.

Why not?
Simple. Intuitive. Flexible.
I dare you Omni – make my dream app.
.
.
.
please?

[curt.clifton]

I'll post this to OmniFocus extras, since that's where this stuff belongs. But I thought for the sake of completeness, it also belongs in this thread.

I've posted a "Verify Next Actions Exist" script to my software downloads page. This scripts scans all projects and action groups to identify those without an identified next action.

[pvonk]

Mathematically speaking, a project is a set, a container for things. What can these things be? Again, from a mathematical point of view, things can be more sets (subsets) or atomic items. In GTD, the atomic items are actions or tasks. When you group several of these together, you have a project.

OF introduces the concept of a subset. Thus this subset lies between a project and a task. In GTD, it could only be a project (thus a subproject of the parent project) or a task (which then contains subtasks). While this structure is not pure GTD, we have it in OF, thus we must accomodate it. So which is it? A subproject or a task containing subtasks?

I believe a task is an atomic item, anything else is a container class, thus a project. However, OF seems to treat this "in-between" object as a task. At least by its icon and its presentation in the views. This is the confusion we have. On top of that, we also have folders and subfolders. Not very Zen-like if you ask me.