Labels

(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.

(Medium) Features that are well understood and relatively straightforward. Bugs that are relatively poorly understood and may not yet have a suggested solution.

(Little more than Medium) Features that are well understood and slightly complex. Bugs that are loosely understood and without a suggested solution.

(Large) Features that are well understood, but known to be hard. Bugs that are very poorly understood, and will not have a suggested solution.

Issues that are created by invalid users Labels created to support the Healthy backlog Initiative (link - to be updated when published)

Issues without any activity for 36+ months Labels created to support the Healthy backlog Initiative (link - to be updated when published)

Issues describes a bug, feature or maintenance effort that is not in line with GitLab strategy or GitLab team members cannot take on in the next 18 months. They may or may not be closed depending on the input from the community, customers and GitLab team members. Labels created to support the Healthy backlog Initiative (link - to be updated when published)

Indicates that issues describes a bug, feature or maintenance effort that is in line with GitLab strategy and GitLab team members can take it on in the next 18 months. These issues will stay open and should be updated regularly (at least once every 6 months). Labels created to support the Healthy backlog Initiative (link - to be updated when published)

Issues that are marked for closure - with some time delay to allow for input by community, customer and gitlab team members that will determine if they get closed or stay open. Labels created to support the Healthy backlog Initiative (link - to be updated when published)

Indicates which maintenance issues should be included in the bug triage - as part of the regular triage process, the backlog scoped label should be modified to either prospective if committed, or no-commitment if not committed to, as well as with a severity label Labels created to support the Healthy backlog Initiative (link - to be updated when published)

Added to MRs that are backports to stable branches. Allows milestone changing automation to skip. See gitlab-org/quality/triage-ops!3450.

This label is added if this MR has been successfully backported

This label is added if this MR needs to be backported

This label is added if this MR does not need to be backported

See https://about.gitlab.com/handbook/engineering/metrics/#data-classification

Issues related to our GitLab Flavored Markdown rendering pipeline, Banzai: https://en.wikipedia.org/wiki/Banzai_Pipeline

Issues belonging to the Collection and Data Exfiltration stage of a Breach and Attack Simulation exercise. See https://about.gitlab.com/handbook/engineering/incubation/breach-and-attack-simulation/#collection--data-exfiltration

Issues belonging to the Command and Control (C2) stage of a Breach and Attack Simulation exercise. See https://about.gitlab.com/handbook/engineering/incubation/breach-and-attack-simulation/#command--control

Issues Destruction stage of a Breach and Attack Simulation exercise. See https://about.gitlab.com/handbook/engineering/incubation/breach-and-attack-simulation/#destruction-simulated

Issues belonging to the External Penetration stage of a Breach and Attack Simulation exercise. See https://about.gitlab.com/handbook/engineering/incubation/breach-and-attack-simulation/#external-penetration