Help track ~group::APM issues after team re-alignment
Plan
-
Short term: migration of all previous ~"group::apm" issues in gitlab-org
to ~"group::apm" + automation:devops-mapping-disable - !624 (closed) -
Medium term (this week/month): work with @sarahwaldner to determine the strategy for ownership of these issues. Implement one-off policies to support any migration needs. -
Long term (next quarter or beyond): Create an automated process which can identify how many Issues/Merge Requests would be "re-labelled" based on a stages.yml
orcategories.yml
change that can be triggered fromwww-gitlab-com
. The process at the moment is manual and holds up changes.- This has happened many times as it's something that requires PMs to remember or follow the process exactly. Feedback or automated notification should be provided within the
www-gitlab-com
pipeline ifstages.yml
orcategories.yml
is changed.
- This has happened many times as it's something that requires PMs to remember or follow the process exactly. Feedback or automated notification should be provided within the
-
Short term: Update documentation at https://about.gitlab.com/handbook/engineering/quality/triage-operations/#auto-labelling-of-issues. - Opened gitlab-com/www-gitlab-com!62380 (merged)
From @sarahwaldner
Hi Quality team. It appears that the triage-bot migrated a large list of issues over the weekend from the group:APM label to the group:health. This has caused a large disruption and a huge mess. Can someone please connect me to someone who knows why this happened?
This is due to the merging of groups. Given that automation works off of stages and categories definition from the handbook this was expected.
Mek: Given that automation works off of stages and categories definition from the handbook this was expected. If we still plan to track group:APM legacy issues we can roll back the bot automated labelling.
Edited by Kyle Wiebers