Quote:
|
Originally Posted by Ken Case
I certainly see how cloned actions would be useful, but they have all sorts of UI ramifications that would introduce a bunch of new work. (For example, an action can be "available" in one project and "not available" due to dependencies in another, so which one is right? In context view, do we list each clone of the action separately, or do we modify the project column to somehow handle multiple project assignments?)
So we won't be doing cloned actions for 1.0, though we'll certainly consider them for future releases.
|
I understand that, and I'll happily wait for a post 1.0 release to include this feature, but without wanting to press the issue, let me try to answer the questions you raise.
Can dependencies arise in one project, where there are none in another, for the very same action, provided the action is well defined, specific, 'atomic', GTD-kosher, so to speak? I think an aliased/cloned action, if it is available in one project, is of necessity available generally. Even if 'Replace tire on car' is not available in sequential project 'Move Furniture', because 'Call friends to ask for help moving furniture' comes first, having the tire replaced as part of a different project won't hurt the 'Move Furniture' project, and it is entirely possible to replace the tire without calling those furniture carrying friends first. Am I overlooking something?
In Context view, I can imagine aliased actions having 'Multiple' as their listed project, while mousing over the word 'Multiple' would reveal all the projects the task is part of.