Description

Managing label sets

• Define/manage sets of labels at the group level.
• So at the group level, you can have distinct sets of labels.
• In the first iteration, there isn't any subgroup support. So for a given group, you have labels at that group level, and you can create sets of labels for that group only. You can't create a set that sucks in labels from a parent/ancestor group.

Configuring label set usage

• At the group level, you define that all issues/merge requests/epics need to use certain label sets defined.

Example

In the GitLab.org group, there are these label sets with these labels:

• Label set called Workflow:
  • The labels in this set are: In Dev, In Review
• Label set called Team
  • The labels in this set are: Discussion, Platform, Distribution
• Label set called Importance
  • The labels in this set are: Deliverable, Stretch

In the GitLab.org group, we decide:

• All issues now have three additional fields corresponding to the three sets.
• All merge requests have two additional fields: Workflow and Importance.
• All epics have one additional field: Team.

Constraint

• The regular label field of an object can have zero, one or many labels.
• The field associates with a named label set of an object can have zero or one label only.

Original description