Help:Triage Process
How we handle issues and use GitLab labels.
Organizational Information
In GitLab, groups are used to manage one or more related projects at the same time. These groups can also be further divided in subgroups to organize content in a more granular way. Projects are the lowest Organizational unit.
Triage Process
Because our projects are related to each other, we use GitLab Labels on a group basis, for the triage process. This allows us to group issues, and merge requests together and work with them as a whole.
Those group labels are inherited from our projects. Other labels, which are only helpful for a specific project exist only on a project basis. Below you find all of them, together with their description.
Our “label structure” and triage process is heavily inspired by the Matrix maintainers .
Issues
An issue is considered triaged when it has the type label and:
- For defects: component, difficulty and a severity or security label.
- For enhancements: component and difficulty label
- For tasks: component and difficulty label
A Milestone or Iteration is assigned to them separately and might change during the process to mark their priority over time. They might change and are not fixed.
When an issue is not part of a milestone or iteration, we generally accept merge requests for them, but they are considered low priority.
Merge Requests
Merge Requests usually only get situational labels assigned.
Group Labels
Group labels are used Globally in our Python Community on Matrix GitLab Group.
Type
Every issue is assigned a type.
Severity
All issues labeled TypeDefect must also have a severity label.
Security
When a TypeDefect is security related it must be labeled with a security label, as well.
| Label | Description |
|---|---|
| SecurityVulnerability | Confirmed vulnerability |
| SecurityPotential | Potential vulnerability |
Difficulty
All issues labeled TypeDefect , TypeEnhancement and TypeTask must also have a difficulty label.
Exceptions
In some cases actions are blocked until something else is resolved. The following labels are used situationally.
Other
In some cases specific marks are used.
Project Labels
Project labels are only used in a specific project and cannot be seen anywhere else in other groups or subgroups.
Exceptions
In some cases actions are blocked until something else is resolved. The following labels are used situational.
| Label | Description |
|---|---|
| ExceptionHugo | Waiting until an upstream issue is fixed or feature is implemented in Hugo |
Components
All issues labeled TypeDefect , TypeEnhancement and TypeTask must also have a component label.
Components are Project specific labels to denote the component affected by the issue.
Maintainers are allowed to create component labels for their components.
Website
This website has content as well. Therefore we have content labels to differentiate between changes to content such as text and media files and pages layout and assets.
| Label | Description |
|---|---|
| ContentWiki | Wiki page changes |
| ContentHelp | Help page changes |
| ContentDocs | Documentation content changes |
| ContentBlog | Blog post or Category changes |
| ContentOther | Other, non-specific content changes |
Maintainer Labels
As maintainer, it is sometimes helpful to group specific content to have a better overview. For that reason maintainers are encouraged to create their own labels.
| Label | Organizational Unit (OU) |
|---|---|
| G-LABEL , G-SCOPELABEL | Group |
| S-LABEL , S-SCOPELABEL | Subgroup |
| P-LABEL , P-SCOPELABEL | Project |
Categories | Contributors |
|---|---|
| Help, Contribute and Shortcode | Michael Sasser |