Labels
Prioritized labels 0
Drag to reorder prioritized labels and change their relative priority.
Labels 3,625
-
automation:ml wrongGitLab.comIssues that were incorrectly triaged/labeled by AI https://gitlab.com/gitlab-org/quality/triage-ops/-/blob/master/policies/stages/report/untriaged-issues.yml
-
automation:quick-win-removedGitLab.comWhen the ~"quick win" label has been automatically removed because it doesn't meet the required criteria: https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#criteria-for-quick-win-issues
-
automation:stale-remindedGitLab.comIdentifies issues / merge requests that have been nudged by the stale reminder
-
availabilitylimitGitLab.comGitLab, like most large applications, enforces limits within certain features. The absences of limits can impact security, performance, and availability. For this reason issues related to limits are considered as another category of ~"type::bug". https://about.gitlab.com/handbook/engineering/quality/issue-triage/#limit-related-bugs
-
backend-weight1GitLab.com(Trivial) The problem is very well understood, no extra investigation is required, the exact solution is already known and just needs to be implemented, no surprises are expected, and no coordination with other teams or people is required.
-
backend-weight2GitLab.com(Small) The problem is well understood and a solution is outlined, but a little bit of extra investigation will probably still be required to realize the solution.
-
backend-weight3GitLab.com(Medium) Features that are well understood and relatively straightforward. Bugs that are relatively poorly understood and may not yet have a suggested solution.
-
backend-weight4GitLab.com(Little more than Medium) Features that are well understood and slightly complex. Bugs that are loosely understood and without a suggested solution.
-
backend-weight5GitLab.com(Large) Features that are well understood, but known to be hard. Bugs that are very poorly understood, and will not have a suggested solution.
-
blocks deploymentsGitLab.comAny item that should prevent deployments to the Main stage of gstg (Staging) and gprd (Production) should have this label applied. This does NOT apply to the Canary stages of these environments.
-
blocks feature-flagsGitLab.comAny item that should prevent feature-flag changes from proceeding should have this label applied.
-
breaking changeGitLab.comA backwards-incompatible change that will need to be made with the next major release. See https://docs.gitlab.com/ee/development/contributing/index.html#breaking-changes