| |
| ### 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](https://rust-lang-nursery.github.io/api-guidelines/checklist.html) and [Secure Rust Guidelines](https://anssi-fr.github.io/rust-guide/) 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](https://github.com/orion-rs/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](https://rust-lang-nursery.github.io/api-guidelines/checklist.html) 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. |
