[frankrei]

Hi,

I'm a total GTD newbie; I have read the book (some months ago) and OmniFocus has rekindled my enthusiasm to use the method again.

Now I find the hierarchal contexts very intuitive, but unfortunately projects don't quite seem to work that way.. there are no hierarchical projects!?

You seem to be able to organize projects into folders, but they seem to have little organizational usefulness because they lack "due dates", contexts, completion flags and pretty much anything.

As a software developer I have:

* a number of software products
* a number of typical activities for each product
* a bunch of versions

So it would be handy to organize things into: "Product A : version 8.0 : Programming", "Product B : version 6.5 : Website", etc.. and organize my projects in that manner.

Unfortunately it looks like that can't really be done because projects aren't hierarchical.. how does one get around that limitation? Or am I totally missing the point?

[Craig]

I (and many others on this forum, I think) use folders as "areas of responsibility" (e.g., "homeowner," "husband/father," "teacher," etc.) which works well for my purposes. I've also seen people use two big folders for "work" and "home."
As I see it, the main functionality that folders do (besides just giving some visual order to your projects list) is facilitating focusing - so you may want to think about in what scenarios you anticipate focusing on groups of projects, and place in folders accordingly.

[Craig]

Also: projects aren't hierarchical, but folders can be. Seems to me like you could nest folders for product and version, with activities projects inside.

[Tim Wood]

I just suggested to Ethan that the topic of when to use folders vs. projects vs. action groups would make a good video.

But as Craig mentioned, folders are most commonly used for areas of responsibility while projects are most commonly used for something that has a desired outcome. In your example, "Product A" doesn't really have an outcome. "Version 8.0" might have a desired outcome, but it is probably going to be pretty large and complicated.

Whenever possible, a project should have a concrete outcome that you can use to determine whether it is really done or not as you are reviewing the project. So, you might have a "Add AppleScript support for parsing tasks in Mail messages" with steps like:

- define grammar with examples
- solicit feedback
- write test cases (starting from examples)
- implement parser
- add white box test cases (now that the implementation is clear)
- fix bugs until all tests pass

I might decide that I'd like to break up 'write test cases' with a bit more detail. Action groups are really free form, but in general we now consider the leaf rows to be the actionable items (action group headers will never show up in context mode, for example) while the action headers provide some context for your review (are there any more test cases I can think of that need writing?) and for scheduling (writing test B doesn't depend on test A, so I could mark that action group parallel).

Hopefully this provides some guidance on when to use folders, projects and action groups. If you have further questions, make sure to post them so Ethan can address possibly them a video =)