本文由 AI 分析生成
Summary
GitLab’s official onboarding checklist for the Issue Triaging team, covering four stages: issue triage with labels, community assistance, shipping a first bug fix, and gaining production access. The role splits 80% community triage and 20% development.
GitLab Issue Triage 團隊的正式入職流程,分四個階段:issue 標籤分類、社群協助、提交第一個 bug fix、取得生產環境存取權限。
Key Points
- Labels are the primary triage tool: each issue should have one category label, one+ team labels, and one+ feature labels
- Regression issues require:
regressionlabel,Next Patch Releaselabel, the release milestone, and a reference in the release’s regression tracking issue - Tools used for production diagnosis: Sentry (error tracking) and Kibana (logging)
- Stage 4 requires production access to the Rails console for investigating and fixing live GitLab.com issues
- The 80/20 split (triage vs. development) is an explicit expectation for team members
Insights
- The four-stage onboarding structure mirrors a capability ladder: understand → reproduce → fix → diagnose in production. This pattern generalizes well to any platform team onboarding.
- Using git blame to find the contributor responsible for a feature is called out explicitly as a triage practice — a non-obvious but practical tip for routing issues quickly.
Connections
- Issues project management guidelines — the broader issue management system this triage process operates within
- Labels project management guidelines — label strategy that triagers must apply
Raw Excerpt
“Labels are the most important feature within the GitLab product for categorizing and organizing issues. Labelling issues correctly will ensure that they are viewed by the correct team members and can be located at a later date.”