This document should grow and change with our code base. Please revise & add anything you think is relevant!
Things You Should Do Before Contributing:
- Learn about object-oriented programming.
- Learn about Markov Chain Monte Carlo algorithms. Ask Jason when you have questions.
- Learn about Orbits for the Impatient (OFTI). Ask Sarah when you have questions.
- Learn about Git and GitHub
- Read our community agreement and (optionally) suggest changes.
Best Practices for Contributing:
- Code according to PEP 8 style standards. When in doubt, check the guide!
- Apply object-oriented principles. Abstract out common functionality whenever possible!
- Document all your code using doc strings
- Put your name on all functions you write in the doc strings. Update contributors.txt periodically so it accurately summarizes your role in the project.
- Write unit tests for your code (see "Unit Testing Instructions" below).
- Don’t edit the
mainbranch directly. Create a new branch and put all of your code there. When you’re happy with your changes, create a pull request, and assign at least Sarah and Jason to review it. When everyone is happy with it, either Sarah or Jason will pull in your changes.
- Each feature should get its own branch to keep things modular. (e.g., don't have a branch like 'Jason-changes' that is a bunch of things all at once). The person assigned to that feature is the lead of the branch.
- Ask for permission from the lead of a branch before contributing to that branch. Helping with a branch is nice, but do ask for permission first since they probably have a picture of what they want to do already.
- Every time you make changes, include a descriptive commit message. The more detail, the better!
Unit Testing Instructions:
When you add some code to
orbitize/orbitize, you should also add some functions to
orbitize/tests (in your development branch, NOT the
main branch). Any test function you write must be named
test_* (see existing tests for examples). You can either create a new file for your test function(s) or add them to an existing
orbitize uses a service called Travis Continuous Integration (CI) to run all properly named tests in
orbitize/tests every time someone adds some commits or creates a pull request. Check out
orbitize's current Travis CI status here.
If you're interested in learning more about how Travis CI tests all of our code, check out their site!
You should test as much of your code as possible (ideally all of it). To check how many lines of code in
orbitize/orbitize are currently being tested by our unit tests, check out our coveralls site.
- modules = all lowercase
- Classes = named with first letter uppercase
- multi-word function names = lowercase with underscores
Releasing a new version:
- Pull all new code to main
- Increment version in __init__
- Update docs changelog (remember to give credit to contributors)
- GitHub release
- Upload new code to PyPi
- Check that new docs are being built