Information for contributors

We (the trackpy Core Contributors) welcome feedback, bug reports, and feature requests, which can be submitted on the project's issues page. Avid users of the project should "watch" it on GitHub so that they can keep up with discussions and changes. But because the project is hosted on GitHub, any member of the trackpy community can also directly propose improvements to the source code. In fact, the project's continued vitality depends on it. The process is not difficult, and we have several successful examples of this and hope to have many more.

Getting started

• Before you write much code, open an issue to gauge the level of interest in your proposed change, and perhaps solicit suggestions about what to do.
• If you're not familiar with the git version control system, now's a great opportunity! GitHub offers some excellent tutorials to get you started.
• Be sure to (re-)install trackpy so that you are running the same version that you are editing. Use pip install -e [path to your copy of the trackpy git repository] or its equivalent.

Creating pull requests

• We generally adhere to the "GitHub Flow", meaning that changes to the source code should be proposed via pull requests.
• Trackpy is a single software package. Its contributors and users have a wide range of priorities, expertise, and skill levels. Expect a lively and friendly discussion around your pull request.

Guidelines for contributed code

Your pull request does not have to conform to these when it is created, but it should by the time it is merged. We can provide guidance.

• Your modified code should pass trackpy's suite of automated tests, starting with tests on your own computer. In the trackpy/tests directory of the source code, run the command nosetests. There may be warnings, but the final output should be "OK".
• When possible, there should be an automated test that exercises each new line of code, and checks its output for correctness where appropriate. Most changes to the source code will require edits or additions to the tests.
• We adhere loosely to PEP8 formatting, in particular its conventions on indentation, blank lines, and comment formatting.

Merging pull requests

• With few exceptions, a pull request should be merged by someone other than its author.
• Only the core contributors have permission to merge a pull request into the master development branch.
• Pull requests that fail continuous integration tests ("Travis CI") should not be merged.