For example, I have a "Repair Window" task in my Projects context. I have a subtask for "call repair man" with a context of Phone. As I'm on my lunch break, I look at my Phone list and go OK I need to call my repair man. We schedule a time to have him come over and he says 'please move any furniture you have in front of the window.' Since I can't do it now, I hit the new task button and put "Move furniture from window" and give it a 'Home' context. Now that task is orphaned, unconnected to the "Repair Window" project. I would have had to navigate to the Projects list, open the "Repair Window" task and then hit "create subtask" inorder for it to be properly categorized. The experiance with the web app, while somewhat simpler, is similar.

I honestly don't understand the obsession people seem to have with linking actions to projects. Are you implying that in the situation above, if you see the task "move furniture" you don't remember why you were supposed to do this?
If you need a link between project and actions, that's a very good sign you are not rigorous enough in your weekly review. The weekly review will tie it all together.
I simply have a project list with no link to any specific actions and I never wonder if a project is without next action or what project an action links to because I review all that on a weekly basis.

I'am currently searching my GTD processes, and your post are very interesting. Obviousy, they don't free me from working on mine.

To mpc_janssen : I hope I will see the answer from other people on your point, but, in my situation :

For me, an task can :
- be achieved after it has been initiated, and I call this kind of tasks 'action' or 'atomic tasks'.
- or it can last more (2 days, 5 days... or more), mainly because the amount of work to complete the task is long.

Knowing this, many of my task are openned in parallel and, event if it is not yet the case, I hope to be able to provide Gantt to people waiting for my tasks to be completed.

All my tasks are atomic (otherwise I will procrastrinate on them) If I have tasks that take several days to complete they are projects for me.
The distinction task/project is not just semantics in GTD. A project is more than just work projects in the normal sense. Any outcome which takes more than one physical activity to complete is a project according to GTD. As a result my project list is as long as my task list.
To give an example if I have a task which takes several hours/days to complete (like prepare workshop for project X) I will add this as a seperate project on my project list and add very specific actions to my next actions list like:

mpc_janssen David Allen has spoken many times about not needing to link your projects to tasks. A projects list is all you need since you shouldn't be looking at your projects daily rather only during your weekly review and just your context/NA list daily. He also has spoken about how poor most all GTD apps are since they do too much and folks will get bogged down with managing tasks and trying to find a way to automate everything which usually doesn't last long till they give up. This has been discussed many times on here, but since a small % of people actually know what a forum is, the audience here is mostly us tech nerds who try to over complicate things. This is one of the main reasons I like Toodledo, I can simplify it very easily by removing features. Dave talks about managing 100 projects with over a hundreds NAs very easily on paper.

All my tasks are atomic (otherwise I will procrastrinate on them) If I have tasks that take several days to complete they are projects for me.
The distinction task/project is not just semantics in GTD. A project is more than just work projects in the normal sense. Any outcome which takes more than one physical activity to complete is a project according to GTD.

In my opinion, one of the serious flaws in GTD, Allen's definition of a project. By his definition, brushing my teeth is a project because it "takes more than one physical activity to complete".

1. Go to bathroom
2. Open cabinet
3. Grasp toothbrush in right hand
4. Grasp toothpaste in left hand
etc.

By Allen's definition, virtually any human activity is a project. It is far to vague to be a definition.

In my opinion, one of the serious flaws in GTD, Allen's definition of a project. By his definition, brushing my teeth is a project because it "takes more than one physical activity to complete".

1. Go to bathroom
2. Open cabinet
3. Grasp toothbrush in right hand
4. Grasp toothpaste in left hand
etc.

By Allen's definition, virtually any human activity is a project. It is far to vague to be a definition.

I don't think that's how David Allen intends a next action, that wont be workable. The way I use next actions is anything I can do in a single context.
Normally brushing my teeth is a single action and I wouldn't even track it because it's not on my mind. However if I find I am out of toothpaste, there is a new physical errand to get toothpaste.
In my experience when I find I have actions I procrastrinate about, it means there is a project behind it or my action is not granular enough.
I think in the parts about the natural planning model DA describes it as "you need to plan as much as is needed to get it off your mind and not more".

In my opinion, one of the serious flaws in GTD, Allen's definition of a project. By his definition, brushing my teeth is a project because it "takes more than one physical activity to complete".

1. Go to bathroom
2. Open cabinet
3. Grasp toothbrush in right hand
4. Grasp toothpaste in left hand
etc.

By Allen's definition, virtually any human activity is a project. It is far to vague to be a definition.

I don't think that's how David Allen intends a next action, that wont be workable.

I don't think I implied, and certainly didn't mean to imply, that's how he meant it. That's why it's a bad definition. It can be easily misinterpreted.

Almost any commonly used word needs multiple definitions to convey its range of meaning. David Allen says very explicitly that the level of granularity in your next actions, which determines what is and is not a project, is up to you. He very explicitly rejects your example as absurd. But if you need a flow chart to brush your teeth, go for it.

I honestly don't understand the obsession people seem to have with linking actions to projects. Are you implying that in the situation above, if you see the task "move furniture" you don't remember why you were supposed to do this?
If you need a link between project and actions, that's a very good sign you are not rigorous enough in your weekly review. The weekly review will tie it all together.
I simply have a project list with no link to any specific actions and I never wonder if a project is without next action or what project an action links to because I review all that on a weekly basis.

I have been wanting to strip my system down in recent weeks and the project to task link is something I would like to stop doing to speed things up. I have a couple of questions about your method (and I'm guessing David Allen does something similar);

1. Do you ever review your project list and wonder if you have done a certain task that you had planned to do but then forgotten?
2. When planning a project, how do you identify and then handle tasks that cannot be done yet?
3. Do you make reflective notes during the weekly review to keep track?

As a long time GTD adherant, I would sugest keeping it simple. GTD is based arround gaining confidence from using a system that you trust to make good choices about what to do next. That is, its a way of management based on intuition.

My setup is very simple.

One folder that lists all my projects; no star, status or any other settings. I do use a due date but only for those projects that actually are due on or by a specific date.

One folder for my Next Actions by context; @home, @office, @errands, @staff meeting, @agendas with a few key people having thier own context (@Tom), etc. I have a couple of standing meetings that I'll throw things I want to discuss in here as well; @staff meeting, etc.

And seperate folders for Waiting For and Someday/Maybe.

Subtasks...NOPE. I used to use them planning out every single next action for every single project (more than 2 actions) and it was too wieldy. My next actions only contain that single next action I need to take to move it forward to completion. I use Evernote for a lot of my large project plans. As for smaller ones, I just use the notes section of the project task.

I do use goals though. These are more in the 30-40k foot level. Not all of them are in TD, but a few are where there is an active project to support their accomplishment.

I have been wanting to strip my system down in recent weeks and the project to task link is something I would like to stop doing to speed things up. I have a couple of questions about your method (and I'm guessing David Allen does something similar);

1. Do you ever review your project list and wonder if you have done a certain task that you had planned to do but then forgotten?
2. When planning a project, how do you identify and then handle tasks that cannot be done yet?
3. Do you make reflective notes during the weekly review to keep track?

Thanks

1. I usually don't forget if I have done a task. At the end of each day, I do a quick daily review (15 mins max) to see what tasks I checked of and if I need to add other next actions for the projects those tasks belong to.
2. If I really need to plan a project, first I do the natural planning up to a level I am comfortable with and store that as project support. If I have to follow a certain order of steps (for instance when applying for official paperwork) I will add the next actions as a note to the project.
3. I don't really take notes during the review although that might be a good way to get more creative.

To ste.witton:

I have had my period of using all bells and whistles in toodledo, but I found that that just made me resent working the system (and spent a huge amount of time to find the 'perfect' setup)
Right now I only use contexts. In essence GTD requires something to track lists. At least Someday/Maybe, Projects, Next action lists per context. And a quick ability to create new temporary lists if needed. In order to keep the system as simple as possible and organizing actions as quick as possible, I use a context for every list.
For the 20.000 feet and up stuff, I am currently not really as organized in those areas as I would like to be, but right now I am tracking that in Evernote.

Almost any commonly used word needs multiple definitions to convey its range of meaning. David Allen says very explicitly that the level of granularity in your next actions, which determines what is and is not a project, is up to you. He very explicitly rejects your example as absurd. But if you need a flow chart to brush your teeth, go for it.

Not sure what "flow chart" you are referring to. I was talking about task managers.

A good definition would preclude such misunderstandings. That's the very purpose of a definition. If Allen had bothered to do a bit if research to define a very important word in his field, he could have easily done much better. Or, just say something like, "A project is whatever you consider it to be in your system". That would have been the equivalent of his definition, but more direct.

mpc_janssen David Allen has spoken many times about not needing to link your projects to tasks. A projects list is all you need since you shouldn't be looking at your projects daily rather only during your weekly review and just your context/NA list daily.

One thing I don't see mentioned is that now with the "Workspaces" feature, you can share folders with other users. For a "Project" in the "project management" style, this seems like it would make Folders and Workspaces an overwhelming favorite for tracking.

I've been using GTD for about 18 months now using Outlook tasks and just transitioned to Toodledo in the last few days. Toodledo supports the GTD model perfectly.

I feel the frustration of others regarding managing Project tasks in the GTD model and thus also in Toodledo. I made this process work using Outlook tasks, prefixes, and categories (similar to tags that can be assigned to more than one project).

I challenge the development community to use Toodledo's APIs and incorporate functionality for project management "best practices" in way that is simple, efficient, and effective. For now, I will use tags and prefixes to support project management in Toodledo but will continue to look for a single tool that supports both GTD and Projects efficiently and effectively and support across all major platforms (iOS, Android/Linux, and Internet).