Every new PR that introduces new functionality must link to an approved issue. PRs without one may be closed at maintainer's discretion.
good-first-issue label or comment)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
// 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: