RFC: Move to epics instead of parent and child issues
Once up a time...
We decided to use Parent and Child Issues in acquisition, conversion and telemetry teams. However, I'd like to see us using epics since dealing with parent/child issues can be cumbersome.
But why did we switch? 🧐
The reasoning for this was that epics had some limitations by not being able to
- add labels
- add milestones
- assign team members
- link issues across projects
🤓
Can we use it today? Yes. Some of these limitations are no longer a concern:
-
✅ Milestones: By changing to a Kanban style, we don't need to have a milestone attached to an epic. Generally, we already had an undefined state for parent issues when they moved through multiple milestones. -
✅ Labels: It is possible to add labels to epics - 🤨 Assigning team members: Not possible, but in my opinion not needed. Issues should be assigned to team members. An epic is a group of those issues.
😯
This sounds too good to be true -
❌ Link issues across projects: It's only possible to link to issues within a group.
Not being able to cross-link is an issue when we tackle tasks that are in different groups. For example tasks that span over gitlab-org
, gitlab-services
or gitlab-com
. At least for acquisition and conversion, most of the work we do, does not span over more than one group.
If work spans over multiple groups, we either create an epic on the other group as well and cross link them (if there will be multiple issues) or just cross link this one issue. In general, we will create epics at gitlab-org
level.
Do we really want epics? 🤨
Oh yes! Some reasons:
- Issue health status in epic tree seems very useful to get a better overview
- Generally a better overview of a project since issue status is always accurate
- It's easy to bulk edit issues
- It's easy to create issues in a bulk (which comes handy for breaking down issues)
- Nice overview of the roadmap
- Dogfooding
🐶 In the longterm epics will improve and be better than our parent/child solution
But Nicolas! There must be downsides, right?
- Work that spans over multiple groups (issue for instance level epics: gitlab-org/gitlab#11402)
- Not being able to assign a team member to an epic
- There is no board to see all epics, just Roadmaps and lists. But in the future there will be Swimlanes which will already help
How to migrate
- All new parent issues should be epics
- Move all parent issues over to epics with Date X (happy to take that over just to proof how much I'd like to move to epics)
- Remove all linkchild issue and linkparent issue labels
Other decisions
- Designs in progress will be in UX issues, using the design tab for conversation, review, feedback, exploration, etc.
- SSOT for finalized designs will be in the epic. Product designers should add a link to their Sketch or Figma prototype to the epic description.