[al_f]

Originally Posted by brianogilvie

The basic planning tools in GTD are (1) a list of actions by context and (2) a list of projects (open loops that can't be done in one physical action). For each project, one should identify the single physical action ("next action") to move that project forward and put it on the appropriate context list.

Actually, there are at least 2 places in the book where David Allen discusses projects with multiple parts and suggests identifying next actions for each part, i.e. says a project can have more than 1 next action. Whether in OF terms you should make each of these parts a project in its own right and group them in a folder or use a single project with several action groups is, I think, a personal decision. I use the latter as it makes more sense to me, but I think OF's design is pushing people in the direction of the former with the current use of the "next" filter.

[dhm2006]

Originally Posted by al_f

Actually, there are at least 2 places in the book where David Allen discusses projects with multiple parts and suggests identifying next actions for each part, i.e. says a project can have more than 1 next action. Whether in OF terms you should make each of these parts a project in its own right and group them in a folder or use a single project with several action groups is, I think, a personal decision. I use the latter as it makes more sense to me, but I think OF's design is pushing people in the direction of the former with the current use of the "next" filter.

Point taken.

However, even in your example, the concept of a next action is still a property of a project or a subproject, not the property of a context. pjc is suggesting that "next action" be a property of context.

His original suggestion for discussion was to change the definition of "next action" to the "first available task in each project within the set of currently selected contexts." He stated that next actions "appear to be considered "next" by project, not by context. This results in some undesirable behavior."

I think next actions *should* be considered "next" by project, not by context, and therefore oppose redefining the term.

However, perhaps there is some other way to address the undesirable behavior (other than redefining "next action"). pjc wants something between "next" and "available." In his words, "In short, 'next' is too narrow for parallel projects, and "available" is too broad, at least for me."

In terms of your comment, I think having the top action of an action group be a "next action" might be helpful. But I still think that each action group/subproject would have only *one* "next action," the one I determine by ordering or reordering the list of actions in the action group.

[pjc]

Originally Posted by dhm2006

I think next actions *should* be considered "next" by project, not by context, and therefore oppose redefining the term.

I think both sides of this discussion have successfully pointed to the relevant portions of GTD supporting their argument. It really isn't clear cut. There's support for "next" being a singular attribute of a project, and there's support for "next" simply to mean the next task available in a project (and availability corresponds to contexts).

I tend toward the latter, but I can understand the perspective that leans toward the former.

That said, I'm certainly willing to look at it from the perspective of terminology. As you observed, I'm looking for some middle ground between "next" and "available" (as currently defined by OF).

Does anybody have any clever ideas? All I've been able to come up with so far is "First Available", renaming the existing available to "All Available" to clarify the distinction:

Next
First Available
All Available
etc.