Automatically apply ~"workflow::validation backlog" to `gitlab-org/gitlab` issues without a workflow label
This is a follow up after https://gitlab.com/gitlab-org/developer-relations/contributor-success/team-task/-/issues/382
was deemed too big (and I was able to collect more data on who is using what, how and why).
Problem to Solve
- Workflow labels are not being used (in the GitLab project: ~27% 50k of 180k).
- It's difficult to query and report on issues. Across the organization, there is no easy way to to find all issues which need validation/need planning/are ready/in development/are complete.
- The current workflow labels were created over time, are unstructured and include some rogue values.
- In a survey, ~45% (36 of 79) team members were unaware of the product development flow.
- Every team have their own workflow process (some examples):
- https://about.gitlab.com/handbook/engineering/workflow/#updating-workflow-labels-throughout-development
- https://about.gitlab.com/handbook/engineering/infrastructure/team/scalability/#workflow-labels
- https://about.gitlab.com/handbook/product-development-flow/
- https://about.gitlab.com/handbook/engineering/development/enablement/systems/gitaly/#agile-workflow-in-gitaly
- https://about.gitlab.com/handbook/engineering/development/sec/govern/sp-ti-planning.html
- https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process
Proposal
What?
Automatically apply workflowvalidation backlog to gitlab-org/gitlab> groupgeo issues without a workflow label.
- A process will be run to update label old issues (this will not generate any notifications, but we are using a dedicated bot/user just in case).
- New issues will automatically be updated by
@gitlab-bot
along with a comment to say why it has been added. - Issue templates will be updated to include guidance on setting the workflow label.
We chose groupgeo as @sranasinghe was in favour and willing.
The group doesn't include the full quad (Product Manager, Product Designer, Engineer, Quality), but will allow us to gauge the outcome and move forward with more groups/projects.
Why?
We can communicate workflowvalidation backlog means across the organization and the wider community; making it clear:
- Raising a merge request for a typefeature is discouraged (prevents setting up for failure)
- Helping validate (especially typebug) is encouraged (providing additional areas to contribute and support product teams)
Product teams will no longer need an "unknown" column in issue/kanban boards and can fully commit to the product development flow.
Notes regarding possible future iterations
1. Create workflow status/group labels
For example: ~"issue::validation" and ~issue::build
Eventually, I would like to have a little more breakdown (perhaps validation//planning//build//complete).
However, these 2 categories are already documented in the product development flow, so perhaps it makes sense to start with them?
I'm unsure however if they add any value?
2. Prevent the use of "rogue" workflow labels?
It makes sense for teams and/or individual issues to skip some workflow steps, but does it make sense to introduce additional steps? And if so, should these additional steps be added to the PDF.
Here is a full list of the current workflow labels, marking whether they exist in PDF or not:
-
✅ workflowvalidation backlog -
✅ workflowproblem validation -
❌ workflowstart -
❌ workflowneeds issue review -
❌ workflowready for design -
✅ workflowdesign -
✅ workflowsolution validation -
✅ workflowplanning breakdown -
❌ workflowissue reviewed -
❌ workflowrefinement -
❌ workflowscheduling -
✅ workflowready for development -
✅ workflowin dev -
✅ workflowin review -
✅ workflowawaiting security release -
✅ workflowblocked -
✅ workflowverification -
❌ workflowstaging -
❌ workflowstaging-canary -
❌ workflowstaging-ref -
❌ workflowcanary -
❌ workflowproduction -
✅ workflowcomplete
We could use the triage-ops bot to remove + notify whoever applies them that they are not meant to be used?
Ultimately, ending up deleting the labels (unless they're used for merge requests).
3. Identify improvement opportunities for the PDF handbook page
As well adoption (both knowledge it exists and usage).