Chapter 9: Tooling and Process: PR Templates, Required Reviewers, SLAs, CI as a Gate

Why this matters

Chapter 4 of the companion Coding Standards book made the case for automating everything mechanically checkable so human attention goes to genuinely judgment-requiring work — this chapter applies the exact same principle to the review process itself. Good tooling doesn't replace good review judgment; it removes friction and inconsistency from everything around the judgment, so reviewers and authors can focus on the parts that actually need a human.

PR templates: consistent context, every time

[BEGINNER] A PR template (a pre-filled structure the author fills in when opening a PR) operationalizes Chapter 3's PR description guidance — rather than relying on every author remembering to include motivation, approach, scope, and testing information, a template makes it the default, visible structure every PR starts from.

<!-- .github/pull_request_template.md -->
## What
<!-- What does this change do, and why is it needed? -->

## Approach
<!-- What approach was taken, and why (especially if non-obvious)? -->

## Out of scope
<!-- What is explicitly NOT addressed by this PR? -->

## Testing
<!-- How was this verified? -->

## Screenshots (if applicable)

Required reviewers and CODEOWNERS

[BEGINNER] A required reviewers or CODEOWNERS configuration automatically requests review from specific people or teams based on which files a PR touches — ensuring, for instance, that changes to a payment module are automatically routed to the team with the relevant domain expertise, rather than relying on the PR author remembering to manually request the right reviewer every time.

# CODEOWNERS file
/src/payments/       @payments-team
/src/auth/           @security-team
/infrastructure/     @platform-team

[SENIOR INSIGHT] This is a direct, practical instance of Chapter 1's shared-ownership purpose, enforced structurally rather than left to individual memory — a change to a security-sensitive area automatically gets a security-aware reviewer, regardless of whether the PR author remembered this was important or happened to think of it.

Review SLAs: making review latency a shared, visible commitment

[IN PRACTICE] Without an explicit expectation, review turnaround time varies wildly and unpredictably, which is a genuine source of team friction (an author blocked for days on a review that should have taken twenty minutes). A review SLA (service level agreement) — a stated, shared expectation like "PRs should receive an initial review within one business day" — makes this expectation explicit and something the team can actually hold itself accountable to, rather than an unstated, inconsistent norm that varies by who happens to notice a PR first.

## Our team's review SLA
- Initial review (first pass, not necessarily approval): within 1 business day.
- For urgent/blocking PRs, tag with `urgent-review` and notify in #team-channel.
- If you can't review within the SLA, comment saying so and when you expect to,
  rather than leaving the author with no information at all.

[SENIOR INSIGHT] An SLA's real value isn't the specific number chosen — it's making review latency a visible, shared team commitment rather than each individual's private, ad hoc priority queue. A team without any stated expectation has no way to distinguish "this reviewer is unusually slow" from "our team's normal is slow," since there's no baseline to compare against — the SLA provides that baseline, making genuine deviations visible and discussable.

CI as a review gate: separating mechanical checks from human judgment

[BEGINNER] Directly the companion Coding Standards book's Chapter 11 principle, applied to the review process: configuring CI to run automatically and block merging on formatting, linting, type-checking, and test failures means a human reviewer never needs to spend review time and attention checking for these — freeing that attention entirely for the genuinely judgment-requiring dimensions from Chapter 4 (correctness of approach, security implications, design fit).

# Branch protection rule: PRs cannot merge unless these checks pass
required_status_checks:
  - lint
  - typecheck
  - test
  - format-check
required_reviews: 1  # at least one human approval, IN ADDITION to passing CI

Common mistakes

1. Relying on every author remembering to include full context in a PR description, rather than using a template that makes it the default structure — inconsistent context quality across PRs is a direct, avoidable tooling gap.
2. Manually assigning reviewers by memory rather than using CODEOWNERS/required-reviewer configuration, risking security- or domain-sensitive changes reaching production without the right expertise reviewing them.
3. Having no stated review SLA, leaving turnaround time as an unpredictable, individually-varying norm with no shared baseline to identify or discuss genuine deviations.
4. Using human review time to catch formatting, linting, or test failures that CI could catch automatically — wasting reviewer attention on mechanically-checkable issues instead of the genuinely judgment-requiring dimensions.

Checklist: setting up effective review tooling and process

1. Configure a PR template covering motivation, approach, scope, and testing, operationalizing Chapter 3's PR description guidance as a default structure.
2. Use CODEOWNERS/required-reviewer configuration to automatically route sensitive or domain-specific changes to the right reviewers, rather than relying on manual memory.
3. Establish and state an explicit review SLA, making review latency a visible, shared team commitment rather than an individually-varying, ad hoc norm.
4. Gate CI on all mechanically-checkable standards (formatting, linting, types, tests) before human review even begins, freeing reviewer attention for genuinely judgment-requiring work.

Discussion / interview questions

1. "What's the value of a PR template, beyond just reminding authors to fill in a description?" Strong answer: Makes consistent, complete context (motivation, approach, scope, testing) the default structure every PR starts from, rather than relying on individual authors to remember what to include — directly operationalizing good PR description practice as a team-wide default rather than an individual discipline.

2. "How does a CODEOWNERS configuration serve code review's shared-ownership purpose?" Strong answer: Automatically routes changes in sensitive or domain-specific areas to reviewers with relevant expertise, structurally ensuring appropriate review coverage rather than depending on the PR author remembering to manually request the right person — a direct, enforced instance of Chapter 1's shared-ownership purpose.

3. "Why would a team benefit from an explicit review SLA, even if the specific time chosen is somewhat arbitrary?" Strong answer: The SLA's value is making review latency a visible, shared commitment with a baseline the team can hold itself accountable to — without one, there's no way to distinguish an unusually slow reviewer from the team's normal, inconsistent pace, since nothing establishes what "normal" should be.

4. "Why should CI checks (linting, formatting, tests) block merging automatically, rather than being left for a human reviewer to check?" Strong answer: These are mechanically checkable with no false positives, so automating them frees human reviewer attention for the genuinely judgment-requiring dimensions (correctness of approach, design fit, security implications) that a tool can't evaluate — directly the same automation principle from the companion Coding Standards book's Chapter 11.

Chapter summary / cheat sheet

• PR templates make consistent, complete context the default, rather than relying on individual author discipline.
• CODEOWNERS/required reviewers structurally enforce appropriate review coverage for sensitive/domain-specific changes — a direct, enforced instance of shared ownership.
• Review SLAs make review latency a visible, shared team commitment, providing a baseline to identify genuine deviations rather than leaving turnaround time as an unpredictable, individually-varying norm.
• CI as a gate automates every mechanically-checkable standard, freeing human review attention for genuinely judgment-requiring work — the same automation principle from the companion Coding Standards book, applied to the review process itself.

---