Skip to content

Latest commit

 

History

History
89 lines (66 loc) · 4.17 KB

CONTRIBUTING.md

File metadata and controls

89 lines (66 loc) · 4.17 KB
Raw

Contributing to the SPIFFE Project

The change management process for the SPIFFE Project is designed to be transparent, fair, and efficient. Anyone may contribute to a project in the SPIFFE repositories that they have read access to, provided they:

To get started:

  • First, README to become familiar with how the SPIFFE Project is managed
  • Make sure you're familiar with our Coding Conventions when appropriate

If you're new to the SPIFFE Project, we recommend that you join us on the mailing lists and Slack to discuss any potential changes you'd like to see made.

If your proposal comes under the purview of a SIG, reach out to the SIG lead and seek their feedback first (bugfixes and changes with minor impact don't need this). The SIG lead may refer you to the broader group.

Sending a pull request

  1. Fork the repo
  2. Commit changes to your fork
  3. Update the docs, if necessary
  4. Ensure your branch is based on the latest commit in main
  5. Ensure all tests pass (see project docs for more information)
  6. Make sure your commit messages contain a Signed-off-by: <your-email-address> line (see git-commit --signoff) to certify the DCO
  7. Open a pull request against the upstream main branch

All changes to SPIFFE projects must be code reviewed in a pull request (this goes for everyone, even those who have merge rights).

After your pull request is submitted

Pull requests are approved according to the process described in our governance policies. At least one maintainer must approve the pull request, and for large changes, another independent reviewer must approve it too.

Once your pull request is submitted, it's your responsibility to:

  • Respond to reviewer's feedback
  • Keep it merge-ready at all times until it has been approved and actually merged

Following approval, the pull request will be merged by the last maintainer to approve the request.

Coding Conventions

Generally, these are the coding conventions SPIFFE projects should follow. Maintainers will consider these conventions when reviewing pull requests.

  • General
    • Command-line flags should use dashes, not underscores
    • Plugin and API protobuf comments are expected to be accompanied with markdowns generated with protoc-gen-doc
    • All documentation and code must conform to the Inclusive Naming Initiative guidelines
    • All filenames should be lowercase
      • Source filenames and directories should use underscores, no dashes (snake case)
      • Document filenames and directories should use dashes rather than underscores (kebab case)
    • Most significant functionality must come with unit tests
    • Significant features should have integration and/or end-to-end tests
    • Unit tests should be fully hermetic. Only access resources in the test binary
    • Concurrent unit test runs must pass
  • Go
  • Bash
  • Python

Third-party code

When third-party code must be included, all licenses must be preserved. This includes modified third-party code and excerpts, as well.

Repositories and Licenses

All repositories under this project should include:

  • A detailed README.md which includes a link back to this file
  • A LICENSE file with the Apache 2.0 license
  • A CODEOWNERS file listing the maintainers

All code projects should use the Apache License version 2.0, and all documentation repositories should use the Creative Commons License version 4.0.