# 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](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests)
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](https://chris.beams.io/posts/git-commit/).

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"](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/incorporating-feedback-in-your-pull-request#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"](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges#squash-and-merge-your-pull-request-commits)
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"](https://docs.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-request-merges#rebase-and-merge-your-pull-request-commits)
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 `just format`, which formats code &
docs according to our style guide.

### Rust

- Make sure code is [`cargo clippy`](https://crates.io/crates/clippy) clean.
  Since we use bazel to build, you can use the `--config=clippy` flag on a bazel
  build command, or run `just clippy` to run clippy on all targets.

### 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.

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

  or

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

## Community Guidelines

This project follows
[Google's Open Source Community Guidelines](https://opensource.google.com/conduct/).
