Preparing repositories for an external code review
· Lindiwe Mokoena
External reviews fail softly when access is partial or documentation lives only in someone’s inbox. A week of preparation usually returns more than a week of extra review time.
Grant read access deliberately
Create a dedicated read-only identity for the reviewer. Include default branches, release tags, and infrastructure folders—even if Terraform lives in a separate repo. If submodules are used, list their URLs in the kickoff doc so clones succeed on the first attempt.
Redact without hiding the truth
Replace production secrets in sample env files with obvious placeholders, but keep the variable names. We need to see that secrets are referenced, not the values themselves. Note any keys that still live in plain text so we can flag rotation steps.
Ship a one-page system map
Boxes for user-facing apps, workers, databases, and third-party callbacks are enough. Hand-drawn photos are acceptable if they name owners and on-call rotations. Mark known pain points you already suspect—review time is better spent confirming than discovering from scratch.
Name your interpreters
Assign one engineer who wrote recent features and one who handles production incidents. Short Slack threads beat long email chains when we ask why a retry policy looks odd.
When you are ready, request a cloud code review or read about migration readiness stages.