Composition Analysis Experiment - Replace sub-issue convention with Epics
Problem to solve
The sub-issue convention looks complicated and adds overhead with issues management. It's a workaround that sounds less necessary as project management features evolve in GitLab. We should instead look toward dogfooding and advocate for improving native features.
Proposal
For the FY21-Q4 quarter, the groupcomposition analysis group will stop following [the sub-issue convention](gitlab-com/www-gitlab-com#4588 (closed) when doing workflowplanning breakdown but instead create usual issues organized under an Epic.
Formal structure
Let's say we have a problem to solve, and after completing the design, we break it down into the following iterative path:
- iteration 1 - 13.2, needs frontend and backend
- iteration 2 - 13.3, needs frontend and backend
- iteration 3 - 13.4, needs frontend and backend
This ends up in the following structures:
Proposal 1:
- EPIC: Problem to solve
- Design issue (closed)
- sub-epic: iteration 1
- sub-epic: iteration 2
- sub-epic: iteration 3
Proposal 2:
- EPIC: Problem to solve
Both proposals come with pros and cons which have been highlighted here: #93 (comment 376006713).
Feedback
Dogfooding Epics as shown need for improvements
- Epics don't have assignees.
- Epics don't have description templates. Having templates to quickly boilerplate the description like with issues is very handy.
- Epics don't have a milestone. While an epic's milestone can be inferred via its child issues, it would be nice to surface it in some way or to be able to set it manually. NB: This is only relevant if we use an epic to reflect an iteration's work.