Workflow and Reviews#

This page describes the contribution workflow from local hooks through PR review.

Pre-Commit Hooks#

Install hooks after cloning:

uv run pre-commit install

Run them manually across the repo with:

uv run pre-commit run --all-files

The configured hooks include a lightweight Markdown link check for README.md, CONTRIBUTING.md, and files under docs/.

Pull Request Process#

Before submitting a PR:

  1. Ensure relevant hooks and tests pass.

  2. Verify the workspace builds cleanly.

  3. Update docs for public changes.

  4. Rebase on the latest main.

Release Tags#

Versioned release tags must be created as raw SemVer tags without a leading v.

  • Use 0.1.0 for stable releases.

  • Use 0.1.0-rc.1 for prereleases.

  • Do not create tags such as v0.1.0 or v0.1.0-rc.1.

This keeps tags aligned with Cargo versions across the workspace. CI still rejects v-prefixed release tags.

For the maintainer release process and release-notes policy, see RELEASING.md.

PR Description#

Include:

  • What changed

  • Why it changed

  • How it was implemented

  • What testing was run

  • Any breaking changes

Review Expectations#

These expectations describe how review is handled before changes are merged.

  • At least one approving review is required.

  • CI must pass before merge

  • Reviewers may request changes for code quality, docs, tests, or architecture.

  • Do not force-push during active review.

DCO Sign-Off#

Every commit in a PR must include a DCO sign-off. Use:

git commit -s

Commit Messages#

Use the format:

type: short description

Common types:

  • feat

  • fix

  • docs

  • test

  • refactor

  • chore

  • perf

Sonar Suppressions#

Use SONAR_IGNORE_START and SONAR_IGNORE_END only for narrow, documented false positives. Keep the suppressed region small and call it out explicitly in the PR description for reviewer sign-off.