Support and syntax for order-dependent subtasks

Registered by Paul Kishimoto on 2010-02-09

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

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)

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.