Engineering retrospectives
Retrospectives capture what we learned from incidents, launches, and sustained periods of engineering work. They are not blame documents: they exist to update runbooks, tests, and process so the same class of failure is less likely or less painful next time.
Cadence
- After significant incidents — Pair with the postmortem; the retro can be a separate meeting or merged into the postmortem review.
- End of milestone or release train — Optional, recommended when multiple teams touched the same surface area.
What a good retro covers
- Timeline and customer impact (facts).
- What went well (preserve it).
- What did not go well (symptoms and contributing factors).
- Action items with owners and due dates (usually tracked in GitHub issues).
Published retrospectives
| Date | Topic | Link |
|---|---|---|
| — | — | No in-tree retrospective pages yet. |
For a worked example of incident-style writeups, see 2024-02-15 login outage postmortem.
When you publish a new retrospective markdown file under docs/projects/retrospectives/, add a row to the table above and link any follow-up issues.