Overview
These are the shared rules we work by. Keep this concise and link deeper pages for details if you contribute to these sections.
Why this exists and why it matters
I have worked with several large tech companies, medium tech, and startups. Each team has standards and a different threshold to balance delivery and quality. However, as each team scaled different contributors and repos evolved their own styles, which led to inconsistent patterns, longer reviews, and onboarding friction. Therefore, we are defining our standards and this serves as a baseline. We all should hold each other accountable in PRs and learn/grow together.
These standards establish a baseline so we can:
- Align on quality and consistency across repos and teams
- Reduce review churn with shared expectations (naming, structure, tests, PR format)
- Speed up onboarding via predictable patterns and checklists
- Improve maintainability and velocity by encouraging small, testable units and DRY, clean code
- Lower risk with clear guidance for error handling, logging, and security hygiene
- Capture and share team knowledge so less lives in DMs and tribal memory
Scope: Applies to all repos under the org. If a repo needs an exception, document it in that repo’s README under Deviations from Standards and link back here.
What’s covered
- Coding — general principles (DRY, clean code), naming, structure, testing, errors
- Pull Requests — what good PRs look like, required sections, checklists
Related (will add later): Git workflow, security, dos/don’ts.
How to use
- Read Coding once, refer back when in doubt.
- Use the PR template for every change.
- Propose updates via PR when something is unclear or routinely violated.