Every new PR that introduces new functionality must link to an approved issue. PRs without one may be closed at maintainer's discretion.
These require design discussion in the issue before coding:
If you can‘t run it, you can’t submit it.
Authors of PRs must run the code locally. “Relying on CI” is not acceptable.
Maintainers will not start reviewing a PR while its CI is failing. Get the pipeline green first - a red build, lint, or test means the PR is not ready for review.
One PR = one thing. Bug fix, refactor, feature - separate PRs. Mixed PRs will be closed.
For Rust code:
cargo fmt --all cargo clippy --all-targets --all-features -- -D warnings cargo build cargo test cargo machete cargo sort --workspace
For other languages, check the README in foreign/{language}/ (e.g., foreign/go/, foreign/java/).
We use typos:
cargo install typos-cli --locked typos typos --write-changes
If it's indeed not a typo, you can set an exception in .typos.toml.
We use HawkEye:
cargo install hawkeye --version "$(cat .github/config/hawkeye.version)" --locked ./scripts/ci/license-headers.sh --check ./scripts/ci/license-headers.sh --fix
We use prek:
cargo install prek
prek install
The hooks require bash >= 4.2 and refuse to run on anything older. Every current Linux distribution already satisfies this.
macOS ships bash 3.2 and never updates it, so this is the one platform that needs a step:
brew install bash
Homebrew's bash has to precede /bin on PATH, which is the default for a Homebrew install but not guaranteed. Check with:
bash --version
Git GUIs launched from the Dock get a minimal PATH where /bin wins, so the hook can still find bash 3.2 after the install. Committing from a terminal avoids this.
// Bad: Increment counter counter += 1; // Good: Offset by 1 because segment IDs are 1-indexed in the wire protocol counter += 1;
Don't comment obvious code. Do explain non-obvious decisions, invariants, and constraints.
Format: type(scope): subject
Good examples from this repo:
fix(server): prevent panic when segment rotates during async persistence fix(server): chunk vectored writes to avoid exceeding IOV_MAX limit feat(server): add SegmentedSlab collection refactor(server): consolidate permissions into metadata crate chore(integration): remove streaming tests superseded by API-level coverage
Keep subject under 72 chars. Use body for details if needed.
Move a PR around the review queue by posting a slash command on its own line in a regular PR comment (not an inline review reply):
| Command | Who | Effect |
|---|---|---|
/ready | author or maintainer | mark S-waiting-on-review |
/author | maintainer or returning contributor | mark S-waiting-on-author |
/request-review @user-or-team ... | author or maintainer | request review from the listed @user / @org/team handles |
Some labels move on their own: opening or marking a non-draft PR ready sets S-waiting-on-review; a “Request changes” review sets S-waiting-on-author; closing or converting to draft clears both.
Commands take up to ~90s. A 👍 reaction means applied, 😕 means you lacked permission; if neither shows up, check the PR Triage Apply run in the Actions tab.
PRs may be closed if: