Contribution guidelines

How to land code in NativeLink — what we accept, how reviews work, what good PRs look like.

NativeLink is source-available, module-aware in its licensing, and accepts contributions from anyone willing to follow these guidelines. We try to make the process predictable.

What we accept

Bug fixes with a regression test.
Performance improvements with reproducible benchmark numbers.
New storage backends, schedulers, worker types discussed in an issue first.
Documentation improvements — including fixing the page you're reading. Smaller is better.
Tooling that makes development or operations easier.

What we don't

Breaking changes to the Remote Execution API surface. We track the upstream spec; changes go there first.
Vendor-specific code paths that only one customer can use.
"Refactoring for its own sake" PRs. Refactor as part of a real change.

Before opening a PR

Open an issue first for anything bigger than a typo fix. Describe the problem and the rough approach. We'll comment within a business day.
Run the test suite locally. bazel test //... or cargo test --workspace. Both should pass.
Run the formatter and linter. cargo fmt --all and cargo clippy --all-targets. CI will reject anything that doesn't.
Sign your commits. We require DCO (Developer Certificate of Origin) on every commit — git commit -s.

What good PRs look like

One change per PR. Small PRs land. Big PRs get split or bounced.
Title in the imperative. "Fix scheduler retry loop on disconnect" — not "Fixes" or "Fixing."
Body answers why, not what. The diff shows what; the body explains the constraint or incident that motivated it.
Tests for new behaviour. Bug fix → regression test. Feature → unit + integration coverage.

Review process

First response within 2 business days. If it's longer, ping us in the PR.
Two reviewers for non-trivial changes. One for typo fixes.
Squash on merge. Every merged PR is one commit on main.

By submitting a PR you agree your contribution is licensed under the license that applies to the file or module you are changing. Most of the repository is FSL-1.1-Apache-2.0; metrics and remote persistent workers are Business Source License modules. See the license page for the practical summary. The DCO sign-off in your commit is the formal declaration.

Meaningful contributors may be eligible for license waivers for Business Source License modules. Open an issue or contact the maintainers before depending on a waiver.

What's next

Pick the dev environment that fits how you work:

Develop with Bazel — the CI-canonical setup.
Develop with Cargo — plain Rust workflow.
Develop with Nix — fully hermetic shell.