| 1 |
# Contributing |
| 2 |
|
| 3 |
First of all, **thank you** for contributing! |
| 4 |
|
| 5 |
Here are a few rules to follow in order to ease code reviews and merging: |
| 6 |
|
| 7 |
- follow [](http://www.php-fig.org/psr/1/PSR-1](http://www.php-fig.org/psr/1/](http://www.php-fig.org/psr/1/) and [](http://www.php-fig.org/psr/2/PSR-2](http://www.php-fig.org/psr/2/](http://www.php-fig.org/psr/2/) |
| 8 |
- run the test suite |
| 9 |
- write (or update) unit tests when applicable |
| 10 |
- write documentation for new features |
| 11 |
- use [](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.htmlcommit messages that make sense](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html) |
| 12 |
|
| 13 |
One may ask you to [](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.htmlsquash your commits](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html) too. This is used to "clean" your pull request before merging it (we don't want commits such as `fix tests`, `fix 2`, `fix 3`, etc.). |
| 14 |
|
| 15 |
When creating your pull request on GitHub, please write a description which gives the context and/or explains why you are creating it. |
| 16 |
|
