CONTRIBUTING.md

How to Contribute

We'd love to accept your patches and contributions to this project. There are just a few small guidelines you need to follow.

Contributor License Agreement

Contributions to this project must be accompanied by a Contributor License Agreement. You (or your employer) retain the copyright to your contribution; this simply gives us permission to use and redistribute your contributions as part of the project. Head over to https://cla.developers.google.com/ to see your current agreements on file or to sign a new one.

You generally only need to submit a CLA once, so if you've already submitted one (even if it was for a different project), you probably don't need to do it again.

Code reviews

All submissions, including submissions by project members, require review. We use GitHub Pull Requests (PR) for this purpose. Consult GitHub Help for more information on using PRs.

For a new review, the author works on a new branch on their own fork of the repository (we don't create additional branches on the main repository).

Once the changes are made locally, the author creates a new commit on their newly created branch based on the main branch, then pushes to their own fork, and creates a PR from the GitHub UI. The author then selects one or more reviewers.

The commit / PR description should follow standard Git commit conventions.

During a review, the author of the change addresses review comments by adding new commits to the same branch / PR and then pushing again (note: we discourage force-pushing to any branch, even during review). The message of these additional commits is unimportant (it can just be "FIXUP" or similar) as these commits will most likely be squashed just before merging, and only the message of the original commit will be kept.

It is not recommended to use the "Applying suggested changes" functionality in the GitHub UI, as this may result in the changes being associated with the wrong user email address, and it also creates a separate commit, which is not necessarily what we want.

In most cases the author expects a single commit out of a PR; once approved, the PR is merged via the "Squash and merge" button in the GitHub UI. The UI will suggest a final commit message composed of the PR title, and individual commit messages as a bullet point list; the author should then reword the final commit message in the UI, usually discarding the message of any additional fixup commit.

In some cases the author intends to keep multiple commits as part of the same PR, in which case they would use the "Rebase and merge" button. Note in this case it is up to the author to make sure that any fixups are squashed against the correct commit if necessary.

Style Guide

Before submitting your PR, we ask you to run ./scripts/docker_run ./scripts/xtask format, which formats code & docs according to our style guide.

Rust

• Make sure code is cargo clippy clean.
• Use the scripts/check_docs script to check for warnings from cargo doc and cargo deadlinks.

C++

• Follow https://google.github.io/styleguide/cppguide.html

• Follow https://abseil.io/tips/

• Use fully qualified names (leading ::) for using declarations and namespace aliases, and avoid fully qualified names for everything else, unless it is necessary to make the code compile.

  namespace oak {
    ...
    Node n;
    grpc::Status s;
    ...
  }

  or

  namespace oak {
    using ::grpc::Status;
    ...
    Node n;
    Status s;
    ...
  }

Community Guidelines

This project follows Google's Open Source Community Guidelines.