Skip to content

Latest commit

 

History

History
79 lines (57 loc) · 3.6 KB

CONTRIBUTING.md

File metadata and controls

79 lines (57 loc) · 3.6 KB
Raw

Contributing to the Tratteria Project

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

To get started:

  • First, README to become familiar with the Tratteria Project.
  • Make sure you're familiar with our Coding Conventions when appropriate

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 Tratteria 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

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 Tratteria projects should follow. Maintainers will consider these conventions when reviewing pull requests.

  • General
    • Command-line flags should use dashes, not underscores
    • 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

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.