Skip to content

Latest commit

 

History

History
41 lines (25 loc) · 2.22 KB

File metadata and controls

41 lines (25 loc) · 2.22 KB

Contributing to OpenRaft

Validate your changes

Run make verify before opening a pull request. It runs the project's formatting, lint, test, and documentation checks, and never modifies your worktree, so what you reviewed is what you submit.

make fix is the mutating counterpart: it applies Clippy fixes, typo fixes, and formatting.

Code style

Beyond rustfmt, OpenRaft follows the conventions in CLAUDE.md. The essentials are:

  • Trait bounds use where clauses, never inline bounds: fn f<T>() where T: RaftLeaderId, not fn f<T: RaftLeaderId>(). This applies to functions, structs, enums, impl blocks, and traits.
  • Each file has one main trait or type and its implementations. Do not reorganize existing files unless the change requires it.
  • Public API changes include a #[since(version = "...", change = "...")] attribute that describes the change.

Documentation

Public documentation lives in Rustdoc comments under openraft/src/docs/ and is published on docs.rs. Update it when a public API or user-facing behavior changes.

Working with git

  • Write commit messages as concise notes to collaborators. The git commit format guide is a useful reference.
  • Before opening a pull request, rebase and squash your branch onto the latest main into one or two logical commits.
  • Do not rebase a published pull request. Merge main into it instead.

AI-assisted contributions

AI tools can help draft a change, but you own every submitted line.

  • Understand each change well enough to defend it in review.
  • Simplify generated output. Remove redundant wrappers, unnecessary abstractions, and comments that repeat the code or claim behavior it does not have.
  • Match the surrounding code and this guide.

PRs that read as unreviewed AI output will be sent back for a cleanup pass before review.

Release checklist

  • make verify passes.
  • The [workspace.package] version in the root Cargo.toml and every sibling path dependency that pins it are updated. Use a prior chore: bump version commit as the complete reference.
  • After release CI finishes, open the release page, update the release notes, and publish.