At GitLab, our mission is to change all creative work from read-only to read-write so that everyone can contribute. GitLab highly values community contribution and we want to continue growing community code contribution. GitLab encourages the community to file issues and open merge requests for our projects on GitLab.com. Their contributions are valuable, and we should handle them as effectively as possible. A central part of this is triage - the process of categorization according to type and product group.
Any GitLab team-member can triage merge requests. Keeping the number of un-triaged merge requests low is essential for maintainability, and is our collective responsibility. Consider triaging a few merge requests around your other responsibilities, or scheduling some time for it on a regular basis.
Triaging all new community merge requests in our projects on GitLab.com is divided between several departments. Quality Department maintains triage automation, Merge Request Coaches take on a partial merge request triage, and finally Engineering Managers in each Product Group are completing the triage process. Additionally, Code Contributor Program drives the community collaboration efforts and works with our community to ensure they receive support and recognition for contributing to GitLab.
We define three levels of triage.
A merge request is considered initially triaged when it has a:
~"Community contribution" label applied.@gitlab-bot user with more details on the process.The Initial triage is automated by the Contributor Success team via the Community contribution thank you note reactive triage automation.
A merge request is considered partially triaged when it has a:
~"type::bug" and ~"UX Debt") It has a severity label applied.~"group:editor"). If no group label exists, the stage label is enough.The Partial triage is completed by Merge Request Coaches via the Newly created community merge requests triage report.
For MRs related to issues, the Partial Triage can be completed by using the following quick action and confirming proper metadata:
/copy_metadata <issue link>
The Complete Triage is divided into 3 subcategories depending on the community merge request state.
A merge request is considered completely triaged when it has:
A merge request is considered completely triaged when it has a:
~"Community contribution" label is merged.This triage process is automated by the Contributor Success team via the Add milestone to community contributions on Triage Operations scheduled triage automation.
A merge request is considered completely triaged when it:
This triage process is being done manually on a case-by-case basis by Merge Request Coaches or Engineering Managers.
The GitLab Website is owned and managed by a different team than GitLab.org; thus, a further triage process must be defined.
A merge request is considered initially triaged when it has a:
~"Community contribution" label applied.@gitlab-bot user with more details on the process.The Initial triage is automated by the Contributor Success team via the Community contribution thank you note reactive triage automation.
The Complete Triage is divided into 3 subcategories depending on the community merge request state.
A merge request is considered completely triaged when it has:
Typically, the reviewer is the code owner of the page the merge request is updated. If there is no code owner assigned, the triager will reach out to the relevant team the page belongs to identify a reviewer.
A merge request is considered completely triaged when it:
This triage process is being done manually on a case-by-case basis by a member of the GitLab Website Community Team or the relevant code owner.
The inactive merge request policy was created to enable GitLab teams to focus efforts on active merge request and prevent old merge requests from degrading into a state of disrepair. This is done by creating two thresholds at which GitLab team members attempt to move the merge request forward.
Contributor Success team members attempt to move merge requests that have reached the first threshold forward via the Community merge requests requiring attention triage report.
If that's not successful an Engineering Manager makes a decision at the second threshold. We value your effort - that's why all decisions to close a merge request are made by a human, and are not automated.
Community contributions are valuable, and we should handle them as effectively as possible to ensure swift feedback to community and increase engagement. To achieve that we define the following Service-level objectives (SLOs):
| Triage Level | Triage SLO | Escalation path if SLO target is missed |
|---|---|---|
| Initial Triage | 24 hours | Reach out to Engineering Productivity team |
| Partial Triage | 7 days | Reach out to the GitLab Website Community Team by directly tagging @gitlab-com-community at the merge request. |
| Complete Triage for Open Merge Requests | - 7 days to assign - 7 days to review |
Reach out to the GitLab Website Community Team by directly tagging @gitlab-com-community at the merge request. |
| Complete Triage for Merged Merge Requests | 7 days | Reach out to Engineering Productivity team |
| Complete Triage for Idle Merge Requests | 7 days | Reach out to the GitLab Website Community Team by directly tagging @gitlab-com-community at the merge request. |