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 Engineering Productivity team, please see Community contributions on Triage Operations page for the full details.
A merge request is considered partially triaged when it has a:
~"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 contribution merge requests triage report.
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 Engineering Productivity team with Triage automation, please see Add milestone to community contributions on Triage Operations page for the full details.
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.
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 Community Relations team |
| Complete Triage for Open Merge Requests | - 7 days to assign - 7 days to review |
Reach out to Community Relations team |
| 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 Community Relations team |
