Labels

For Support<>Fulfillment: ONLY L&R Support DRIs should apply this label to an issue or epic to identify it as a top priority from Support. No more than 10 open issues and epics should have this priority at any time. See https://handbook.gitlab.com/handbook/support/license-and-renewals/workflows/managing_product_issues/

For Support<>Fulfillment: ONLY L&R Support DRIs should apply this label to an issue or epic to identify it as a lower priority item on Support's Issue List for Fulfillment. See https://handbook.gitlab.com/handbook/support/license-and-renewals/workflows/managing_product_issues/

For Support<>Fulfillment: ONLY L&R Support DRIs should apply this label to an issue or epic to identify it as a low priority item on Support's Issue List for Fulfillment. See https://handbook.gitlab.com/handbook/support/license-and-renewals/workflows/managing_product_issues/

For Support<>Fulfillment: Used when initially identifying a new or existing issue or epic as one to be included in Support's Issue List for Fulfillment. This identifies the item as needing to be categorized. See https://handbook.gitlab.com/handbook/support/license-and-renewals/workflows/managing_product_issues/

For Support<>Fulfillment: Use to indicate that the issue or epic on Support's Issue List for Fulfillment needs to be reviewed for possible reprioritization. Comment on the issue or epic outlining how you think it should be prioritized and your reasoning. See https://handbook.gitlab.com/handbook/support/license-and-renewals/workflows/managing_product_issues/

For Support<>Fulfillment: ONLY L&R Support DRIs should apply this label to an issue or epic to identify it as a child of a prioritized epic on Support's Issue List for Fulfillment. See https://handbook.gitlab.com/handbook/support/license-and-renewals/workflows/managing_product_issues/

Use this label in addition to workflow labels to indicate that the UX department engaged in problem validation for this issue.

Use this label in addition to workflow labels to indicate that the UX department engaged in solution validation for this issue.

Issues related to building accessibility into our internal workflows

Issues related to the Merge Request approvals feature: http://doc.gitlab.com/ee/workflow/merge_request_approvals.html

If a change is made to something like a template or project label, it could potentially be disruptive to the workflow of the teams using it, so we will log those actions.

Issues that have been updated in accordance with our issue triage policies (https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/contributing/issue_workflow.md)

When 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

Used by teams that want to designate an issue as blocked without changing the workflow scoped label

Active issues for this quarter that address internal technical debt or improve workflow processes in support of the open source growth strategy: https://about.gitlab.com/handbook/engineering/open-source/growth-strategy.html