How we work

Process & Guidelines

Code Review

Review Requirement: Before merging to the main branch, all production code must be reviewed by a peer other than the author via a Pull Request in GitHub.
Review the product, not just the code: Start by reading the Linear ticket. Does this PR actually address the stated customer need? Click around. Check the UX. Don't just read diffs.
Review Process: Conduct code reviews synchronously in person or via screen sharing. The author explains their changes line by line to the reviewer.
Review Approval: Reviewer approves the Pull Request in GitHub.
Pair Programming: If code is developed jointly, a formal review can be skipped, but the Review Approval is still required.
Comments: Feedback from non-reviewers is optional for the author to address unless marked as a blocker.
- [blocker] - potential release risk/correctness/security issue. Tag the author and ping in Slack/IRL.

Back End vs Front End Review Standards

Back end (DB, Elasticsearch, BYOC, core data models, API logic): requires careful, thorough review. Don't LGTM on a quick skim.
Front end: working code that isn't wildly off-pattern is fine.

AI-Generated Code

If you're generating code with AI tools, be the first and most critical reviewer of your own output. Read every line, understand it, and exercise it in the application before putting up a PR.

Design Review

For tickets that touch significant UI/UX changes, add a "design review needed" label. Design gets eyes on it before it's enabled for customers. This does not block your merge, but it blocks customer-facing rollout.