RFC: Engineering Review Rotation System
Summary
This MR proposes an Engineering Review Rotation system to address misaligned incentives around code review at GitLab.
Problem
- Teams are measured on delivery metrics (MR throughput, velocity, interlock timelines)
- None of these metrics incentivize cross-team reviews
- Reviews compete with rewarded activities, leading to delays and resentment
- The Maintainership Working Group identified reviewer burnout as a significant issue
Proposed Solution
A scheduled rotation where engineers have dedicated shifts for reviewing MRs. During a shift, reviewing is the engineer's primary responsibility.
Key elements:
- Two tracks: Separate Reviewer and Maintainer rotations
- Trainee priority: Trainee maintainers preferred for rotation to accelerate their path to maintainership
- Supplements existing process: Does NOT exempt anyone from normal roulette/review expectations
- Predictable capacity: Teams can plan for rotation like PTO
Success Metrics (justified by industry benchmarks)
| Metric | Target | Justification |
|---|---|---|
| Time to First Review | ↓20%+ | Conservative; Google achieves ~4h median, MS/ISE achieved 30-50% reduction |
| Review SLO Compliance | >90% | High-performing teams: 85-95% |
Industry context:
- Google: "One business day is the maximum time to respond" (vs GitLab's 2-day SLO)
- DORA elite teams: <4h median time-to-first-review
Phased Rollout
- Phase 1 (3mo): Database specialty pilot (volunteer-based)
- Phase 2 (3mo): Expand to Backend
- Phase 3 (3mo): Add Frontend; full rollout
- Phase 4: Continuous improvement
Request for Comment
This is an RFC seeking feedback from across engineering. Key questions:
- Is 1-week shift duration right, or would shorter be better?
- Should rotation be mandatory or opt-in?
- How should participation factor into performance reviews?
- What tooling would help?
Please comment on this MR or in #engineering Slack.