Skip to content

Latest commit

 

History

History
58 lines (34 loc) · 3.02 KB

CONTRIBUTING.md

File metadata and controls

58 lines (34 loc) · 3.02 KB
Raw

1. What to contribute

There are a variety of things that one may contribute to this project. Contributions of any kind are always welcomed.

1.1 Features and Improvements

Improvements to the library can come in many flavors: performance, security, usability, etc. An improvement that doesn't add new features or are breaking changes, may be submitted as pull requests directly.

Features that add new functionality or are breaking changes should preferably be discussed in a separate issue first.

See Rust API Guidelines and Secure Rust Guidelines for some checklists on how to implement new features.

1.2 Testing

One way to contribute to testing is by writing new unit-tests to cover code that isn't already being tested. Improvements to existing unit-tests is also an option.

Adding test vectors (located in /tests) is also a good way to improve the testing of the library. Test vectors can be official or generated using another crypto library.

1.3 Fuzzing

Fuzzing is an important part of testing this library. Contributions to this aspect can come in two ways: 1) Running the fuzzing targets, updating the corpus and reporting any issues found and 2) Overall improvements to the fuzzing targets.

Please refer to the orion-fuzz repository when working with fuzzing.

1.4 Documentation

Quality of documentation is a vital part of this project. Contributions to this could include adding documentation where such is missing, clarifying documentation that is unclear or improving examples.

Try to make changes adhere to the Rust API Guidelines as much as possible.

2. Bug Reports and Feature Requests

There are templates for both these scenarios, please see the .github/ISSUE_TEMPLATE/ directory.

A bug report or feature request should ideally follow the provided templates. It's not a strict requirement but in most cases, more information about the bug or feature makes it easier to fix/evaluate.

3. Pull Requests

Before submitting a pull request, please make sure you have done the following:

  • Explain what the pull request changes, in the description of the GitHub PR, or link to the relevant issue.

  • A change or addition of functionality is covered by unit-tests.

  • Ensure that all tests pass when running:

    • cargo test
    • cargo +nightly test --no-default-features

  • The formatting is correct and clippy does not show warnings by running:

    • cargo clippy
    • cargo fmt

  • If you have changed or added tests, you can make sure these also pass CI by checking:

    • cargo clippy --tests

  • If the pull request is a bugfix, try to include a regression test for the bug.

All pull requests should be opened against the master branch.

If your pull request is still work-in-progress, make the title of the pull request start with WIP: or open it as a draft via GitHub.