Skip to content

Latest commit

 

History

History
73 lines (61 loc) · 3.59 KB

CONTRIBUTING.md

File metadata and controls

73 lines (61 loc) · 3.59 KB

Contributing

The Hipcheck project is happy to accept contributions! We want Hipcheck to be the best possible toolkit for assessing risks in open source software.

Before Contributing

We recommend you do a few things before contributing to the project:

  • Read the Hipcheck Values: The Hipcheck project has a list of values for the product and the project, enumerated in RFD #2.
  • Read the Code of Conduct: We require all participants in the project and in project-controlled spaces like our Discussions forum to follow the Code of Conduct. This outlines expectations, procedures for reporting violations, and means of enforcement.
  • Read the Contributing Guide: We maintain a guide to contributing to Hipcheck on our project website, which covers the mechanics of coordinating changes, testing changes, licensing, and more.

When Contributing

The expectations for a contribution vary depending on how substantial it is.

  • Small Contributions, including bug fixes, minor documentation changes like edits for grammar, spelling, or clarity, or code quality improvements which don't impact functionality, should be submitted by:
    1. Optionally, opening an issue in the issue tracker explaining the problem and proposing the change.
    2. Submitting a PR with the change, requesting review from the Hipcheck Maintainers team.
  • Larger Contributions, including changes to functionality of Hipcheck or proposals for changes to the plugin protocol, should:
    1. Start with an issue in the issue tracker.
    2. If large enough, may require an RFD. You can learn more about the RFD process from "RFD #0: The RFD Process."
    3. Submit a PR with the change, requesting review from the Hipcheck Maintainers team.

We also recommend checking out our public roadmap to understand our current priorities.

When making contributions, we do have some expectations:

  • Signoff Commits: We enforce a Developer Certificate of Origin and require signoff on all commits. When you open a PR, there's a GitHub Action that checks for this.
  • Builds on Supported Platforms: We require builds to pass on all platforms for which we provide prebuilt binaries. This is checked in CI.
  • Passes All Tests: We require passing tests on all supported platforms as well. This is checked in CI.
  • Formatting, Linting: We run all changes against cargo fmt and cargo clippy to ensure they're meeting our style guidelines.
  • Document Your Changes: If you're making a change which impacts an API, we expect that you will update documentation to reflect your changes.
  • Conventional Commits: We enforce Conventional Commits in CI. Commit messages must indicate what kind of change is being made.

Many of the above items can be checked locally with the command cargo xtask ci. Even more, such as cross-platform passing tests, is checked in CI on a PR.