1# Contribute 2 3Thank you for contributing! 4 5Before we can merge your Pull-Request here are some guidelines that you need to follow. 6These guidelines exist not to annoy you, but to keep the code base clean, unified and future proof. 7 8## Coding Standard 9 10This project uses [PHP_CodeSniffer](https://github.com/squizlabs/PHP_CodeSniffer) to enforce coding standards. 11The coding standard rules are defined in the **phpcs.xml.dist** file (part of this repository). 12The project follows a relaxed version of the Doctrine Coding standards v4. 13 14Your Pull-Request must be compliant with the said standard. 15To check your code you can run `vendor/bin/phpcs`. This command will give you a list of violations in your code (if any). 16The most common errors can be automatically fixed just by running `vendor/bin/phpcbf`. 17 18## Dependencies 19 20We're using [`composer/composer`](https://github.com/composer/composer) to manage dependencies 21 22## Unit-Tests 23 24Please try to add a test for your pull-request. This project uses [PHPUnit](https://phpunit.de/) as testing framework. 25 26You can run the unit-tests by calling `vendor/bin/phpunit`. 27 28New features without tests can't be merged. 29 30 31## Documentation 32 33The documentation is stored in the `doc` folder and is written using the [rST](http://docutils.sourceforge.net/rst.html) language. 34If you are adding a new feature, you must update the documentation. 35 36To test doc rendering before submitting your PR, you will need [Sphinx](http://www.sphinx-doc.org/en/stable/). 37 38To install `Sphinx` just run: 39 40```bash 41pip install --requirement doc/requirements.txt --user 42``` 43 44When that is done, just run: 45 46```bash 47cd doc && sphinx-build -W -b html -d _build/doctrees . _build/html 48``` 49 50## CI 51 52We automatically run your pull request through [Travis CI](https://www.travis-ci.org) 53and [Scrutinizer CI](https://scrutinizer-ci.com/). 54If you break the tests, we cannot merge your code, 55so please make sure that your code is working before opening up a Pull-Request. 56 57## Issues and Bugs 58 59To create a new issue, you can use the GitHub issue tracking system. 60Please try to avoid opening support-related tickets. For support related questions please use more appropriate 61channels as Q&A platforms (such as Stackoverflow), Forums, Local PHP user groups. 62 63If you are a Symfony user, please try to distinguish between issues related to the Bundle and issues related to this 64library. 65 66## Getting merged 67 68Please allow us time to review your pull requests. 69We will give our best to review everything as fast as possible, but cannot always live up to our own expectations. 70 71Please, write [commit messages that make 72sense](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html), 73and [rebase your branch](http://git-scm.com/book/en/Git-Branching-Rebasing) 74before submitting your Pull Request. 75 76One may ask you to [squash your 77commits](http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html) 78too. This is used to "clean" your Pull Request before merging it (we don't want 79commits such as "fix tests", "fix 2", "fix 3", etc.). 80 81Pull requests without tests most probably will not be merged. 82Documentation PRs obviously do not require tests. 83 84Thank you very much again for your contribution! 85