|
| 1 | +Contributing |
| 2 | +============ |
| 3 | + |
| 4 | +Pull requests are more than welcome — both to the library and to the |
| 5 | +documentation. Some useful information: |
| 6 | + |
| 7 | +- We aim to follow PEP 8 in the library, but ignoring the |
| 8 | + 79-character-per-line limit, instead following a soft limit of 99, |
| 9 | + but allowing lines over this where it is the readable thing to do. |
| 10 | + |
| 11 | +- We aim to follow PEP 257 for all docstrings, and make them properly |
| 12 | + parseable by Sphinx while generating API documentation. |
| 13 | + |
| 14 | +- We keep ``pyflakes`` reporting no errors or warnings at all times. |
| 15 | + |
| 16 | +- We keep the master branch passing all tests at all times on all |
| 17 | + supported versions. |
| 18 | + |
| 19 | +`Travis CI <https://travis-ci.org/html5lib/html5lib-python/>`_ is run |
| 20 | +against all pull requests and should enforce all of the above. |
| 21 | + |
| 22 | +We use `Opera Critic <https://critic.hoppipolla.co.uk/>`_ as an external |
| 23 | +code-review tool, which uses your GitHub login to authenticate. You'll |
| 24 | +get email notifications for issues raised in the review. |
| 25 | + |
| 26 | +Patch submission guidelines |
| 27 | +--------------------------- |
| 28 | + |
| 29 | +- **Create a new Git branch specific to your change.** Do not put |
| 30 | + multiple fixes/features in the same pull request. If you find an |
| 31 | + unrelated bug, create a distinct branch and submit a separate pull |
| 32 | + request for the bugfix. This makes life much easier for maintainers |
| 33 | + and will speed up merging your patches. |
| 34 | + |
| 35 | +- **Write a test** whenever possible. Following existing tests is often |
| 36 | + easiest, and a good way to tell whether the feature you're modifying |
| 37 | + is easily testable. |
| 38 | + |
| 39 | +- **Make sure documentation is updated.** Keep docstrings current, and |
| 40 | + if necessary, update the Sphinx documentation in ``doc/``. |
| 41 | + |
| 42 | +- **Add a changelog entry** at the top of ``CHANGES.rst`` following |
| 43 | + existing entries' styles. Don't forget to attribute yourself. |
| 44 | + |
| 45 | +- **Run tests with tox** if possible, to make sure your changes are |
| 46 | + compatible with all supported Python versions. |
| 47 | + |
| 48 | +- **Squash commits** before submitting the pull request so that a single |
| 49 | + commit contains the entire change, and only that change (see the first |
| 50 | + bullet). |
| 51 | + |
| 52 | +- **Don't rebase after creating the pull request.** Merge with upstream, |
| 53 | + if necessary, and use ``git commit --fixup`` for fixing issues raised |
| 54 | + in a Critic review or by a failing Travis build. The reviewer will |
| 55 | + squash and rebase your pull request while accepting it. Even though |
| 56 | + GitHub won't recognize the pull request as accepted, the squashed |
| 57 | + commits will properly specify you as the author. |
0 commit comments