# Contributing Guidelines

Your input is amazing! Making contributing to this project as easy and transparent as possible is one of the most
important side, this includes:

- Reporting a bug
- Discussing the current state of the code
- Submitting a fix
- Proposing new features
- Becoming a maintainer

## Wanted changes

- New features
- Bug fixing
- Better documentation
- Fixing of spelling and grammatical issues

## Unwanted changes

- Whitespaces and punctuation changes
- Word changes using synonyms
- Entire rewrites of the project, or parts of the project - unless first approved by a maintainer

## All code changes happen through pull requests

Pull requests are the best way to propose changes to the codebase. We actively welcome your pull requests:

1. Fork the repo and create your branch from `main`
2. Keep consistency with the current state of the codebase
3. Format the code of the files properly, make sure to run `rustfmt` and `clippy` to lint before pushing
4. Issue that pull request!

## Commit messages guidelines

This project uses [`Conventional Commits 1.0.0`](https://conventionalcommits.org/en/v1.0.0/) hence your commit messages
**must** follow the same convention or your contributions will be ignored, refused or assigned to another user or
maintainer.

It would be more than welcome to keep your contributions as a single commit rather than, for examples, 20 `"fix: Stuff"`
commits in-between. You may use multiple commits if you believe the changes made in these commits have nothing, or close
to nothing, in common - feel free to ask a maintainer on whether it should be a single commit or not.

## Create a GitHub Issue and **then** a pull request

Start contributing by first opening a new issue. Once that is done, you can create a pull request for the issue if you
already have a fix for it.

## License

Your submissions are understood to be under the same [MIT License](LICENSE.md) that covers the project.