---

• Fork the project on GitHub.
• Add the forked project to your repository remotes.
• Create a new branch.
• Add your changes to a new commit in your new branch.
• Push your new branch to your forked repository.
• Create a pull request from the GitHub interface.

• Commit early and often, prefer a real history of smaller commits over one giant commit
• Write useful commit messages, be clear, brief and to the point

Any newly written code should follow the coding conventions. However, as not all existing code follows these strictly yet, small patches may opt to follow the existing style of surrounding code to maintain readability.

Do not hide your changes in a giant auto-formatting commit. If you do this your PR will be rejected, and commits will be reverted. Any commits that reformat an existing file, or mass-rename variables, must be separate, not hide any changes, follow the coding conventions, and not negatively affect the readability of the code. The only exception is during code refactoring.

Here's a real example of a very bad commit. As you can see, it becomes very difficult to review and accept such patches when the changes are hidden in unnecessary auto-formatting noise.

{.is-warning}