doc
7 years ago
src
7 years ago
CONTRIBUTING.md
7 years ago
LICENSE
7 years ago
README.md
7 years ago
composer.json
7 years ago
CONTRIBUTING.md
16 lines
| 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 |