I read about related issues and subtasks (including this). And now I’m utterly confused about what use case the subtask is intended for.
If I understand correctly a subtask is just a type of related issues that automatically enforces the following workflow:
- the parent task’s done percentage is the sum of the subtasks’ done percentages
- the parent task’s deadline is the deadline of the last subtask
- the parent task’s spent time is the sum of the subtasks’ spent times
- the parent task’s priority is the highest of the subtasks’ priorties
Without these 4 bullet points, a subtask would be no different from a simple “related to” (ignoring some UI differences). Correct?
At first glance, I thought if S1 and S2 are subtasks for T, it means that S1 and S2 are steps to complete T. But clearly that’s not the use case behind subtask:
First, because in my use case, S1 and S2 block T, but subtask relationship doesn’t imply this.
Second, because in my use case the priorities of S1 and S2 are driven by T’s priority, but with a subtask the priority of T is instead driven by S1 and S2.
So there must be a canonical use case for subtasks that I am missing. What is it?
EDIT:
To make things more confusing, this issue suggests that maybe the above workflow should be potentially removed. If that happens, how is subtask different from a simple “related to”?
The way I have used it in the past, subtasks exist to break a larger feature down into manageable / assignable chunks, in a way that is more management-friendly than simply doing relations using
blocked-by,follows, etc.There are a lot of features in Redmine/ChiliProject that exist for flexibility, i.e. to let a user or a group manage the project their way, without trying to shoehorn their workflow or thought process into a box built around somebody else’s workflow. I would argue that subtasks are one of them; they are useful to some, useless to others, and downright dangerous to still more people.