Any GitLab team-member can triage issues. Keeping the number of un-triaged issues low is essential for maintainability, and is our collective responsibility.
We have implemented automation and tooling to handle this at scale and distribute the load to each team or group.
Video introduction to triage operations, triage report, priority and severity labels.
The Quality Engineering Department ensures that every Product and Engineering group is held accountable to deliver on the SLA set forth.
Our defect SLA can be viewed at:
The Quality Engineering department employs a number of tools and automation in addition to manual intervention to help us achieve this goal. The work in this area can been seen in our department roadmap under Triage and Measure tracks of work.
Be sure to give a heads-up in the relevant Slack channels (e.g. #development,
#product) and the company call when an automation is expected to triage more
than 100 issues or merge requests at once.
That is usually the case when migrating labels (e.g. migrating team labels to stage/group labels).
There is a large amount of automation that uses stage, group, and category labels. We ask that Product Managers create an issue in triage-ops when any of the following changes occur. This issue helps ensure limited to no impact to automation and reports.
Regarding legacy team labels, the mapping can be seen in Automation to ensure that issues and MRs with legacy team labels have a 1:1 mapping to their devops stage or group label.
Our triage bot will automatically infer stage and group labels based on the category/feature and team labels already set on an issue. This is available for open issues.
The most important rules are:
The following logic was initially implemented in this merge request:
Check out the list of actual use-cases to better understand what this flow means in practice.
If your issue doesn't belong to a particular stage, you can remove the stage
label and add the ~"automation:devops-mapping-disable" label to prevent this
automation from happening in the future.
We currently auto label open and merged merge requests based on the legacy team labels. The mapping can be seen in Automation to ensure that issues and MRs with legacy team labels have a 1:1 mapping to their devops stage or group label.
If your merge request doesn't belong to a particular stage, you can remove the stage
label and add the ~"automation:devops-mapping-disable" label to prevent this
automation from happening in the future.
A triage report is an issue containing a checklist of issues requiring attention. Each task corresponds to an issue that needs labels, prioritization and/or scheduling.
An issue created by a triage report is automatically assigned to team members. Those team members are listed in group definition file, or the respective triage report policy YAML files.
To change who an issue gets assigned to, open a merge request for the above files.
This report contains the 66 most recent unlabelled issues requiring initial triage. The goal is to ensure we achieve partial triage before the issue is picked up by a Product Manager and Engineering Manager in that area.
If identified as a duplicate bug, the new issue can be closed with a note similar to:
Hey @author. Thanks for raising an issue. I've checked this for you and found this has already been reported in the following issue(s):
* #issues
Please add your thoughts and feedback on the original issue.
Closing this issue in favour of the original.
/duplicate #issues
If identified as a duplicate feature proposal, the new issue can be closed with a note similar to:
Hey @author. Thanks for your request. I've checked this for you and found this has already been proposed in the following issue(s):
* #issues
Please add your thoughts and feedback on the original issue. Don't forget to upvote!
Closing this in favour of the original issue.
/duplicate #issues
Use this template to provide resources and close the issue:
Hey @author. Based on the information given, this request for support is out of the scope of the Issue tracker (which is for new Bug Reports and Feature Proposals). Unfortunately, I won't be able to help get it resolved. However, for support requests we have several resources that you can use to find help and support from the Community, including:
* [Technical Support for Paid Tiers](https://about.gitlab.com/support/)
* [Community Forum](https://forum.gitlab.com/)
* [Reference Documents and Videos](https://about.gitlab.com/get-help/#references)
Please refer to our [Support page](https://about.gitlab.com/support/) for more information.
If you believe this was closed in error, please feel free to re-open the issue.
/label ~"support request"
/close
~"awaiting feedback" label.@abuse-team.This report contains the relevant bugs, feature requests, and UX debt issues that belong to a group in our DevOps stages. The goal is to achieve complete-triage by the Product Manager, Engineering Manager, UX team member in that area.
The report itself is divided into 4 main parts.
~P1 and ~P2 bugs past the target SLO.The bug sections also contains a heatmap.
An example: https://gitlab.com/gitlab-org/quality/triage-ops/issues/118
Video overview of the triage report.
There is also an optional stage policy for missing categories. If your team has enabled this, you will receive a list of up to 100 items that have the stage label but have zero appropriate category labels for that stage.
This section contains issues with the ~"feature" label without a milestone. It is divided further into issues with and without ~"customer"
Backlog or Awaiting further demand milestone.This section contains issues with the ~"bug" and ~"frontend" labels without priority and severity. It is divided further into issues with and without ~"customer"
Backlog.This section contains issues with the ~"bug" label without priority and severity. It is divided further into issues with and without ~"customer"
Backlog.This section contains bugs which has past our targeted SLO based on the priority set. This is based on our missed SLO detection triage policy.
This report contains idle merge requests that belong to a group in our DevOps stages.
Some merge requests are being idle with no activity on them and are merged more than 30 days from the time when they are opened. This report attempts to collect them for identifying the actions we need to take.
An example: Fill me
This report contains open merge requests which has been submitted by the wider
community. These merge requests would have the ~"Community contribution" label.
The report itself is divided into 2 parts. The first part contains the 20 newest merge requests from the wider community. The second part contains 20 merge requests that weren't updated for 2 months or more.
General triage automation is run to label and update issues which help with reporting and milestone transition.
Open issues and merge requests that have missed the current release will be rescheduled to the next active milestone. This identifies pending work that was not completed within the planned milestone.
>= 19th if the 22nd is on a Monday>= 20th if the 22nd is on a Sunday>= 21st otherwise~missed:x.y is applied, where x.y is the current milestone~Deliverable label, the ~missed-deliverable label is appliedOpen issues and merge requests planned as ~Deliverable but have a ~missed:x.y
label will have the ~missed-deliverable label applied.
~Deliverable
label and a ~missed:x.y label, and no ~missed-deliverable label.~missed-deliverable is applied.Issues which have a label of ~Deliverable without a milestone will have the milestone set to %Backlog.
~Deliverable without a milestone~Deliverable label is removed%BacklogIssues which have a priority and missed the SLO target will be labeled with ~missed-SLO. The calculation for elapsed time starts from the date of the priority label being applied. This enables reporting on SLO target adherence.
~P1 and ~P2 bugs.~missed-SLO is applied.When milestone is present on an issue but there is not an assignee. The milestone being present indicates the product team has reviewed and scheduled the issue. This encourages open source contributions for planned features.
Issues with the ~workflow::blocked label are excluded from this rule.
~"Accepting merge request" label is applied.Issues or merge requests that have a label of ~master:broken will have labels of ~P1 and ~S1 applied. This ensures that requests which break master are sufficiently categorized for reporting.
~master:broken label.~P1 and ~S1 labels are applied.This automation identifies potential and popular proposals using upvotes. This helps identify feature proposals that people have indicated they would like.
~"potential proposal" or ~"popular proposal" is applied depending on the condition.Merge requests which have an author that is not a member of gitlab-org will have a label of ~"Community contribution" applied. This informs the GitLab community team about new community contributions.
gitlab-org group.~"Community contribution" is appliedMerged merge requests with the ~"Community contribution" label and no milestone will automatically get the relevant milestone set. This helps keep the community contributions numbers accurate.
~"Community contribution" label, and no milestone.merged_at of the merge request and the start_date and due_date of the milestone