Introduce Issue Stages
Our current implementation of the Issue Board is based around labels, which means that if we want to add new functionality to the board, we have to alter the way that labels work.
Problems
That poses the following problems, among others:
-
Inability to use the Issue Board and auto-close at the same time: Users want to keep using the board while their issues are being deployed or gathering feedback, but they also want to auto-close issues when code merges so a change can be reflected in Cycle Analytics. The problem is that closing an issue moves it to the
Done
column, so what users end up doing is reopening those issues after they're auto-closed and using them in a sort of limbo state. -
Closing an issue from outside the board does not remove its list labels: This will change with #29277 (moved), but either behavior feels unnatural. We don't want to keep list labels on issues if they're not in a board, but we also don't want to magically change users' content through obscure rules.
-
Labels overload. Labels are supposed to represent categories. We are now trying to use them to represent the status of issues too, which comes with its own rules and complex behaviors. Using the same entity for both functionalities has led us to a situation where labels perform neither task properly.
Proposal
I propose we introduce Stages. A Stage represents an issue's status beyond Open and Closed. A project's flow may be defined by the following stages:
- To do
- Design
- Development
- Review
- Testing
- Staging
- Production
- Feeback
With this new entity, each Issue Board list can be backed up by one single Stage. An issue cannot be in two stages at the same time, so it really represents how each issue travels through a team's workflow. We could even say that Closed
is the last stage of all.
Stages also tie into Cycle Analytics. We currently provide 7 stages that go from Issue
to Production
and we map each of them to different events in an issue's lifetime. If we match Issue Stages with Cycle Analytics Stages, we can give users the ability to really represent their own cycle. We would still provide them with our 7 initial stages, but they could add their own and discard the ones they're not interested in.
Users can move an issue from one stage to another in three different ways:
- They can use the Issue Board to move it between columns
- They can change the Stage attribute in the issuable sidebar through a new option
- They can define triggers
Users can define triggers in their project settings so their issues automatically advance from one stage to the next. Some triggers could be:
- When
code merges
, move issue toTesting
stage - When
tests pipeline succees
, move issue toStaging
stage - When
code deploys
, move issue toProduction
Why is this better?
I think introducing Stages and replacing labels on issue boards allows us to accomplish the following:
-
Labels can go back to simply representing categories
-
We have a natural way to keep issues in the board after code merge
-
We can advance an issue in Cycle Analytics without having to close it
-
We can map Cycle Analytics 1:1 with an attribute inside each issue
-
When an automatic event happens, it doesn't come as a surprise to the user because they were the one who defined the trigger that made it happen