You're reading this, so you actually so you actually want to contribute. Good!
This is some quick information to get you started. At the bottom you find a list of useful links for further reference.
If you are using the library and find a bug in the code, an error in the documentation, or simply have a question:
Open the issue tracker, search and check if there is already an issue on your topic and, if not, write a new one! If you do so, please
- be specific,
- be concise,
- provide a Minimal Working (or rather failing) Example,
- point to a code location if possible,
- send a patch if you have a fix.
To just get acquainted to the code, clone the repository -- you don't need a GitHub account for this step. A good starting point are the examples.
If you want to implement a new great feature, create your own fork of the repository (requires a GitHub account). You may want to read all of the development section in the documentation.
Once you are done with your feature,
- write tests for it (untested code is buggy code),
- document your new shiny code -- we follow the NumPy/Scipy style,
- check the coding style -- the great tool autopep8 will help you save time,
- when you're ready, send a pull request -- we'll check your code and get back to you.
The ownership of your code remains with you, as documented by the commits in the Git history. You don't need to sign any CLA whatsoever, and there's no assignment of copyright.
Here's a short list of tools which make life as a developer much easier:
- Spyder -- a great development environment
- Pylint -- angry code checker (integrated in Spyder)
- autopep8 -- automatically reformat your source according to PEP8
- pytest -- run unit tests, including PEP8 style checking using
pytest --pep8 - pep257 -- check if your docstrings are in line with PEP257
- GitHub markdown -- helps you write nice and well-structured texts on the issue tracker