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