Skip to content

Latest commit

 

History

History
56 lines (34 loc) · 3.86 KB

CONTRIBUTING.md

File metadata and controls

56 lines (34 loc) · 3.86 KB
Raw

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.opennetworking.org/ 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.

Submitting Code

General Information

Stratum follows Google's Engineering Practices, C++ Style Guide and unit test rules. Use these documents as a guide when submitting code.

Some additional points:

  • Submit your changes early and often. GitHub has Draft PRs that allow you to share your code with others during development. Input and corrections early in the process prevent huge changes later.

  • Stratum uses a squash and rebase model. You do not have to do this by hand! GitHub will guide you through it, if possible.

  • Consider opening a separate issue describing the technical details there and link it to the PR. This keeps code review and design discussions clean.

Steps to Follow

  1. Fork Stratum into your personal or organization account via the fork button on GitHub.

  2. Make your code changes.

  3. Pass all unit tests locally. Create new tests for new code and add the targets to the build-targets.txt and test-targets.txt files in the same PR, so CI can pick them up! Execute the following command in the Stratum root directory to run all currently enabled tests: xargs -a .circleci/test-targets.txt bazel test

  4. Check code style compliance with cpplint and clang-format (pre-installed in development docker container). If you're editing Bazel files, consider buildifier as well (also pre-installed).

  5. Create a Pull Request. Consider allowing maintainers to make changes if you want direct assistance from maintainers.

  6. Wait for CI checks to pass. You can check the coverage report after they ran. Repeat steps 3. and 4. as necessary. Passing CI is mandatory. If the CI check does not run automatically, make sure you unfollow your fork on CircleCI.

  7. Await review. Everyone can comment on code changes, but only Collaborators and above can give final review approval. All changes must get at least one approval. Join one of the communication channels to request a review or to bring additional attention to your PR.

Community Guidelines

This project follows Google's Open Source Community Guidelines and ONF's Code of Conduct.