Thanks, Bill. I see your point but the solution still seems to me like a patch up job. Let's take a sequential project as an example:
Code:
PROJECT MyProject [sequential]
Group_Task_A [sequential or parallel (doesn't matter)]
Task_A.1
Task_A.2
Task_B
Following yours and Ken's suggested setup, Group_Task_A and MyProject are assigned no context. Also following your suggestion, I have chosen to hide groups and projects from the "no context" bin.
Now, like most people, during the day I tend to use the context view alone to get things done. I only use the project view for my daily and weekly reviews. Let's assume that early in the morning I complete Task_A.1 and Task_ A.2. The next actionable step is now Task_B, which will not be released until Group_Task_A is checked off. In this setup, however, this group task will be visible only in the project view which, as I said, I never bother to (and should not have to!) review more than once during the day. As a result, I miss the opportunity to complete Task_B before my next daily review.
The only solution is to ensure that groups and projects are automatically marked as completed upon completing their children. This however has serious workflow implications (disadvantages), as we all know.
In short, using OF feels to me more "precarious" and "unpredictable" than before. There are too many parameters to take into consideration and yet, ironically, the user feels that less degrees of freedom are available in setting up and using the system, because every solution involves a compromise.
All such problems—this overall lack of transparency—would be instantly resolved if group actions and projects had separate fields for their own context and for their children's default context. Or (as has been suggested) if projects and groups were automatically placed in a hard-wired bin dedicated to these two types of entities. Despite the apparent increase of information and complexity, this solution would actually simplify things in terms of usability. I feel that the developers' understanding of "complexity vs. simplicity"—and their express intention to "simplify" this application—is misguided in this case.