Thank you for your interest in contributing to the MAHF ecosystem! We welcome contributions from the community to help make this project better.
Before you get started, please take a moment to read through these contribution guidelines to ensure a smooth and collaborative experience.
We welcome contributions in various forms, including bug reports, feature requests, code contributions, and improvements to documentation.
In general, if you find an issue that addresses the problem you're having, please add your own reproduction information to the existing issue rather than creating a new one. Adding a reaction can also help be indicating to our maintainers that a particular problem is affecting more than just the reporter.
If you encounter a bug, please open an issue with a detailed description of the problem, steps to reproduce it, and any relevant error messages. Additionally, please annotate your issue with the bug label.
If you have an idea for an enhancement or a new feature, please open an issue with a clear description of the proposed change and its potential benefits. Additionally, please annotate your issue with the enhancement label.
Improvements to documentation are always appreciated. If you find any errors or areas that need clarification, please submit a pull request with your changes.
In general, we follow the "fork-and-pull" Git workflow:
- Fork the repository to your own GitHub account.
- Clone the project to your machine.
- Create a branch locally with a succinct but descriptive name.
- Commit changes to the branch following commit message guidelines.
- Ensure your code follows our code guidelines.
- Push changes to your fork.
- Open a PR in our repository and describe the changes you've made.
PRs to our projects are always welcome and can be a quick way to get your fix or improvement slated for the next release.
When submitting a PR, please:
- Provide a clear and concise title and description.
- Reference any related issues in your pull request description.
- Ensure that your code passes the CI.
- Be prepared to address feedback and make necessary changes.
For changes that address core functionality or would require breaking changes (e.g. a major release), it's best to open an issue to discuss your proposal first. This is not required but can save time creating and reviewing changes.
Our projects have strict guidelines for styling, testing, and documenting code.
Note that the CI checks master and PRs into master for compliance to the guidelines.
If the CI fails on your PR, please check and fix the errors.
Clippy with the -D warnings flag is used to perform linting checks.
Run Clippy
$ cargo clippy --workspace --all-targets --all-features -- -D warningsRustfmt is used to enforce consistent code formatting with the options specified in rustfmt.toml.
Some options require running rustfmt with the nightly toolchain. Note that the nightly toolchain is only required for rustfmt, and not for building.
Run Rustfmt
$ cargo +nightly fmt --all -- --check --verboseTesting is a critical aspect of maintaining code quality.
If your changes affect existing tests, please update them to accommodate for the new behaviour. If you add a new feature that can be tested, add unit tests to check for correct behaviour.
Run tests
$ cargo test --workspace --all-features --lib --bins --tests --examples --verbosePlease add or update the documentation for all public items affected by your changes.
The documentation should build without any errors or warnings.
Build docs
$ export RUSTDOCFLAGS = -D warnings
$ cargo doc --no-deps --verbosePlease add examples for all public methods.
Run doctests
$ cargo test --workspace --all-features --doc --verboseBy contributing to this project, you agree to license your contributions under the GNU General Public License v3.0.