Skip to content

Latest commit

 

History

History
48 lines (34 loc) · 3.67 KB

contributor_guidelines.md

File metadata and controls

48 lines (34 loc) · 3.67 KB
Raw

This document should grow and change with our code base. Please revise & add anything you think is relevant!

Things You Should Do Before Contributing:

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 main branch 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/tests/test_* file.

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.

Notes:

  • Naming practices:

    • 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