Support and syntax for order-dependent subtasks
Several bugs deal with ordering subtasks, and there is some disagreement on how they should be handled, represented in the UI, and entered. See the discussion on the attached bugs. Use the whiteboard for discussion.
Blueprint information
- Status:
- Not started
- Approver:
- None
- Priority:
- Undefined
- Drafter:
- None
- Direction:
- Needs approval
- Assignee:
- Izidor Matušov
- Definition:
- Drafting
- Series goal:
- None
- Implementation:
-
Not started
- Milestone target:
- None
- Started by
- Completed by
Related branches
Related bugs
Sprints
Whiteboard
2010-02-22 khaeru — three kinds of ideas that have been expressed:
1. "Use-pattern": Users should learn to make tasks which come earlier children of tasks which come later:
- Third
-- Second
--- First
2. "Data model": The task data model should be extended to either (A) store an 'order' property or (B) interpret the order that subtasks are listed in the parent task body as a deliberated ordering. GTG would need to alter these according to user action.
3. "Task name + helpers": Alpha sorting in the tree view should be exploited, by prepending "1", "2", "3" etc. to task names. GTG can help assign/change these based on drag-drop behaviour.
Comments on each follow.
"Use-pattern"
khaeru — my problem is that if "First" and "Second" are topically unrelated, it feels unnatural to make one a child of the other. What if I want to show a "loose" preference that "First" be done before "Second"...but not have to un-child it if I end up doing it in the opposite order?
"Data model"
khaeru — (A) It would be hard to tell when this property was influencing task display order unless it was included as its own column in the Task Browser. (B) It would be hard to choose where to cut/paste the subtasks within the parent task body.
"Task name + helpers"
khaeru — could also be "1: ", "2: "; "1st", "2nd"; "1ier", "2ieme" (localized), as long as it sorted. You could mix ordered and unordered tasks.
2011-08-22 Elrond : I think, there is a fourth way:
4. dependency tracking.
That is, task2 can't start before task1 has been done.
- One suggestion is to abuse the start date and let it point to a different task.
- Another suggesion is to have a new dependency property of a task, which can refer to any other task, that should be done first.
Comments:
Elrond: This is way more flexible than all the other three suggestions. The major problem here is, that one needs to detect dependency loops (simple example: A depends on B, B depends on A)
