This is the org-wide baseline. Each repo's own README / CONTRIBUTING covers
setup and any repo-specific rules that go beyond this.
- Branch off the repo's default branch. (It varies by repo —
main,master, orrelease— check before branching.) Recommended name:<type>/<ticket>/<short-desc>, where<type>is one offeatfixchorerefactortestperf.WMS repos enforce a
(IB|CI|OB)-FUL-<digits>ticket format in the branch name; other squads follow their own ticket prefix. Match your repo's convention. - Commit using Conventional Commits
(
feat:,fix:,chore:, …) and reference the ClickUp card. - Before pushing, run the repo's formatter + linter (
prettier/eslintfor TS/JS,rufffor Python). Let the pre-commit / pre-push hooks run. - Open a PR against the default branch, fill in the template (What / Why / How to test), and make sure CI is green.
- Get one approving review. Any teammate can approve — you can't approve your own PR. Resolve all review comments before merging. If you push new commits, the approval resets, so get a fresh one.
- Merge — merge commits only (no squash/rebase); the branch is deleted automatically after merge.
An approval means you actually looked. You don't need to understand every line, but you should know what the PR does and why. If you can't tell, ask the author before approving.
Dependency, CI, container, and config files are owned by @stackbox-dev/dev-leads
via CODEOWNERS in the repos that define it — those changes need a dev-lead's review.
Full access model and repo standards: see the sop repo (github-teams.md,
github-repo-standards.md).