Hierarchical task inheritance, etc.
 

Is there a thread in here somewhere that explains behavior and best practices for setting things like project, context, estimated hours, dates, review, and the like when you have hierarchical tasks or projects and actions or the like.

Where do you do the settings? Either level? Both, if appropriate? What effect does the absense of a setting have in the various ways of viewing tasks and projects?

Well, I was just disappointed to find that a sequential project with a due date attached to a later action does NOT make the preceding actions due, too. That is, given this:

Project: apply for grant (seq)
- pick up forms @errands (no due date)
- fill out forms @work (no due date)
- turn in forms @errands (due 10/1)

If I viewed my available actions by due date, "pick up forms" would show up as having "None." This is technically correct, but means that the actual urgency of this project won't show up in context view until the last action is up, which may be too late!

[Submitted via feedback.]

[QUOTE=Craig;22359]Well, I was just disappointed to find that a sequential project with a due date attached to a later action does NOT make the preceding actions due, too. That is, given this:

Project: apply for grant (seq)
- pick up forms @errands (no due date)
- fill out forms @work (no due date)
- turn in forms @errands (due 10/1)

If I viewed my available actions by due date, "pick up forms" would show up as having "None." This is technically correct, but means that the actual urgency of this project won't show up in context view until the last action is up, which may be too late![/QUOTE]

I made a suggesion some time ago that might also help in this type of situation. I called it cascading due dates, but perhaps relative due dates would be a better description. I think it would be useful, especially for templates or for projects that have on a specific due date around which everything else in the project revolves, such as a conference.

The idea is as follows:

-- The due date for the project as a whole or for a key action in the project is set to a date certain (i.e., 18 July 2008).
-- The due dates for related actions are set as relative dates (relative to the project date or key action date), for example: two days before, two weeks before, three days after, three months after, etc. (similar to how repeat dates are set for individual actions).
-- Then, if the date certain (the due date for the project or key action) changes, the other related due dates change automatically.

This would avoid having to change all of the due dates for the related items individually, which can get very time-consuming, especially for repeating projects.

[QUOTE=Craig;22359]Well, I was just disappointed to find that a sequential project with a due date attached to a later action does NOT make the preceding actions due, too. That is, given this:

Project: apply for grant (seq)
- pick up forms @errands (no due date)
- fill out forms @work (no due date)
- turn in forms @errands (due 10/1)

If I viewed my available actions by due date, "pick up forms" would show up as having "None." This is technically correct, but means that the actual urgency of this project won't show up in context view until the last action is up, which may be too late!

[Submitted via feedback.][/QUOTE]

Craig,

You probably know this, but for other readers the solution is to set the due date of the parent project to 10/1. If you have additional actions that happen after 10/1, then you can group the actions leading up to the deadline into an action group:

Project: apply for grant (seq)
- Completed application (due 10/1)
--- pick up forms @errands (no due date)
--- fill out forms @work (no due date)
--- turn in forms @errands (no due date)
- From funding agency, update on grant status (no due date)

Thanks Curt, that's helpful and I'll try to remember to structure things that way from now on. But I hope I'm not alone in wishing that OF's present date logic were changed so that an action with a specified due date would roll that same due date into earlier (otherwise unspecified) actions in the sequence. The fact that it doesn't seems like a considerable problem in having a "trusted system."

@dhm2006, I think that would be a helpful feature.

[QUOTE=Frosty Crunch;22355]Is there a thread in here somewhere that explains behavior and best practices for setting things like project, context, estimated hours, dates, review, and the like when you have hierarchical tasks or projects and actions or the like.

Where do you do the settings? Either level? Both, if appropriate? What effect does the absense of a setting have in the various ways of viewing tasks and projects?[/QUOTE]

Frosty,

Back to your original question -- I cannot remember or find a thread (or a few threads together) that address your entire question. There are a lot of threads that discuss different parts of your question. Maybe if you broke it down a little ...