AR8: Engineering standards and code review
Templates, ownership and changing the standards
🎯You'll be able to
Use a pull request template to build good habits, and set up a way for the team to change its standards so they stay owned and current.
🏠The everyday picture
A housing society's rules are changed at the general meeting, by a proposal and a vote, and every resident gets the new copy. Rules handed down without a say get ignored; rules changed by whoever shouts loudest get chaotic.
📘What it really is
-
A pull request template asks authors for a summary, how it was tested, risks and rollback, and a checklist link. It moves the review's first questions to the author.
-
Ownership: standards work when the team writes and changes them, not when they're imposed.
-
A change process: anyone proposes a change with a reason; bigger changes are written as an ADR; tech leads decide on a regular cadence; the version goes up and everyone hears.
-
Review the whole document on a schedule (for example every six months), and remove rules that no longer help.
- Code owners: a file listing which team reviews which folders, so the right people see each change.
📝A worked example
Input: RasoiRoute has no PR template, and its standards have no way to change.
Steps:
- Template: Summary, How it was tested, Risks and rollback, Checklist linking
docs/review-checklist.md. - Standards header: "Version: 1.1", "Last reviewed: 2026-10-20".
- "Changing these standards": propose in a pull request; ADR for platform-wide changes; decided fortnightly by the three tech leads; version up and the team channel told the same day.
- First proposal: add R11 (calls to other services have a deadline and a key), from Project 2.
Expected output: a template, a versioned standards document and a change process, with one change made through it.
🌍Where it's used
- Code hosting platforms support pull request templates and code owners files.
- Large engineering organisations run request-for-comments processes for standards.
- Regulated teams keep versioned standards for audits.
📝Case scenario
A tech lead wrote standards alone over a weekend and announced them on Monday. Within a month, several teams had quietly switched rules off. The next version was drafted with one engineer from each team, with a proposal process; adoption followed because the teams had shaped it.
🖱️Try it
Write a pull request template for a project of yours with the four sections above. Success: a reviewer reading a filled-in template would know how to test and undo the change.
⚠️Common mistakes
- Standards imposed from above. Sign: rules switched off quietly. Fix: draft and change them with the team.
- No version or date. Sign: nobody knows which rules apply. Fix: version and "Last reviewed".
- Templates people delete. Sign: empty sections. Fix: keep it short and use it in review.
🛠️For your project
Project 3's test 10 checks .github/pull_request_template.md and the Version, Last reviewed and "Changing these standards" parts of
docs/standards.md.
✅Quick check
What does a pull request template do for reviewers?
Show the answer
It asks the author for the summary, testing, risks and rollback before review starts.
Why should the team be able to change its standards?
Show the answer
So the standards stay current and owned by the people who follow them.