# 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.