Contribution Guidelines
=======================
Overview
--------
Contributing to this project is easy, and reporting an issue or adding
to the documentation also improves things for every user. You don't need
to be a developer to contribute.
Reporting issues
~~~~~~~~~~~~~~~~
Please use the *GitHub issue tracker*, and describe your problem so that
it can be easily reproduced. Providing relevant version information on
the project itself and your environment helps with that.
Improving documentation
~~~~~~~~~~~~~~~~~~~~~~~
The easiest way to provide examples or related documentation that helps
other users is the *GitHub wiki*.
If you are comfortable with the Sphinx documentation tool, you can also
prepare a pull request with changes to the core documentation. GitHub's
built-in text editor makes this especially easy, when you choose the
*“Create a new branch for this commit and start a pull request”* option
on saving. Small fixes for typos and the like are a matter of minutes
when using that tool.
Code contributions
~~~~~~~~~~~~~~~~~~
Here's a quick guide to improve the code:
1. Fork the repo, and clone the fork to your machine.
2. Add your improvements, the technical details are further below.
3. Run the tests and make sure they're passing (``invoke test``).
4. Check for violations of code conventions (``invoke check``).
5. Make sure the documentation builds without errors
(``invoke build --docs``).
6. Push to your fork and submit a `pull
request `__.
Please be patient while waiting for a review. Life & work tend to
interfere.
Details on contributing code
----------------------------
This project is written in `Python `__, and the
documentation is generated using
`Sphinx `__.
`setuptools `__
and `Invoke `__ are used to build and manage
the project. Tests are written and executed using
`pytest `__ and `tox `__.
Set up a working development environment
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
To set up a working directory from your own fork, follow `these
steps `__, but
replace the repository ``https`` URLs with SSH ones that point to your
fork.
For that to work on Debian type systems, you need the ``git``,
``python``, and ``python-virtualenv`` packages installed. Other
distributions are similar.
Add your changes to a feature branch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For any cohesive set of changes, create a *new* branch based on the
current upstream ``master``, with a name reflecting the essence of your
improvement.
.. code:: sh
git branch "name-for-my-fixes" origin/master
git checkout "name-for-my-fixes"
… make changes…
invoke ci # check output for broken tests, or PEP8 violations and the like
… commit changes…
git push origin "name-for-my-fixes"
Please don't create large lumps of unrelated changes in a single pull
request. Also take extra care to avoid spurious changes, like mass
whitespace diffs. All Python sources use spaces to indent, not TABs.
Make sure your changes work
~~~~~~~~~~~~~~~~~~~~~~~~~~~
Some things that will increase the chance that your pull request is
accepted:
- Follow style conventions you see used in the source already (and read
`PEP8 `__).
- Include tests that fail *without* your code, and pass *with* it. Only
minor refactoring and documentation changes require no new tests. If
you are adding functionality or fixing a bug, please also add a test
for it!
- Update any documentation or examples impacted by your change.
- Styling conventions and code quality are checked with
``invoke check``, tests are run using ``invoke test``, and the docs
can be built locally using ``invoke build --docs``.
Following these hints also expedites the whole procedure, since it
avoids unnecessary feedback cycles.