Contributing to SLEAP
Contributing to SLEAP#
As our community grows it is important to adhere to a set of contribution guidelines. These guidelines may change as needed. Please feel free to propose changes to source code in a pull request!
Table Of Contents#
Code of Conduct#
Everyone contributing to SLEAP is governed by the SLEAP Code of Conduct. As such, all are expected to abide by this code. Please report any unacceptable behavior to
Github has made it easy to separate issues from discussions. Generally speaking, if something warrants a pull request (e.g. bug fixes, TODOs) it should be submitted as an issue. Conversely, general questions about usage and improvement ideas should go into discussions. These both act as staging areas before adding the items to the SLEAP Roadmap. Once added to the Roadmap, items can be given priority, status, assignee(s), etc.
This is a place to go to ask questions and propose new ideas.
3 categories: Help, Ideas, General
Help - Having trouble with software, user experience issue, etc.
Ideas - Enhancements, things that would make the user experience nicer but not necessarily a problem with the code.
General - If it doesn’t fall into help/ideas it goes here as long as it isn’t bug fix (issue).
Install source code
developbranch and follow instructions to create conda env, etc.
Create a fork from the
Either work on the
developbranch or create a new branch (recommended if tackling multiple issues at a time).
If creating a branch, use your name followed by a relevant keyword for your changes, eg:
git checkout -b john/some_issue
Make some changes/additions to the source code that tackle the issue(s).
Can either write tests before creating a draft PR, or submit draft PR (to get code coverage statistics via codecov) and then write tests to narrow down error prone lines.
The test(s) should go into relevant subtest folders to the proposed change(s).
Test(s) should aim to hit every point in the proposed change(s) - cover edge cases to best of your ability.
Try to hit code coverage points.
Add files, commit, and push to origin.
Create a draft PR on Github (follow instructions in template).
Make sure the tests pass and code coverage is good.
If either the tests or code coverage fail, repeat steps 3-5.
Once the draft PR looks good, convert to a finalized PR (hit the
ready for reviewbutton).
IMPORTANT: Only convert to a finalized PR when you believe your changes are ready to be merged.
Optionally assign a reviewer on the right of the screen - otherwise a member of the SLEAP developer team will self-assign themselves.
If the reviewer requests changes, repeat steps 3-5 and
Once the reviewer signs off they will squash + merge the PR into the
New feautures will be available on the
mainbranch when a new release of SLEAP is released.
Code - Generally follow PEP8. Type hinting is encouraged.
Documentation - Use Google-style comments and docstrings to document code.
Thank you for contributing to SLEAP!#