Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.
Types of Contributions
If you are reporting a bug, please make sure you provide
A reproducible data example (including all package imports, data imports and full code). This may mean that you will need to “dumb”-down your problem.
Beyond that, please provide
Your operating system name and version.
Any details about your local setup that might be helpful in troubleshooting.
Look through the GitHub issues for bugs. Anything tagged with “bug” and “help wanted” is open to whoever wants to implement it. If you are fixing bugs please add additional tests to capture what the bug was.
Look through the GitHub issues for features. Anything tagged with “enhancement” and “help wanted” is open to whoever wants to implement it. Additionally, if you see anything in the future goals that looks interesting to develop please feel free to reach out to Ben via email to connect.
You can never have enough documentation! Please feel free to contribute to any part of the documentation, such as the official docs, docstrings, or even on the web in blog posts, articles, and such.
We’ll be explaining this section to describe how we automate this process (and highlight the easy of contributing to documentation) soon. We’re taking “pages” from Anne Gentle who has writes books on good continuous integration style documentation and gives talks on things like simple github based documentation pages. An additional useful resource to what types of docs do we need might be writethedocs.org’s guide.
Write Additional Tests
Generally speaking, the more tests the better. Additionally, given this was developed as a “statistical package”, many functions and classes were not created in a “test-driven” fashion, so capturing additional use cases/edge case is looking upon favorably.
svg and general objects we use the
pytest-regressions package (and
image_regression tools. A member of the development team
gave a talk at PyCon 2020 which can be found on youtube
here. Beyond this talk and
package documentation don’t
capture how to use the tool clearly enough please see the
Given this is a “statistical package” (in some sense), we are also leveraging
hypothesis python package.
If you are proposing a feature:
Explain in detail how it would work.
Keep the scope as narrow as possible, to make it easier to implement.
Remember that this is a volunteer-driven project, and that contributions are welcome :)
Ready to contribute? Here’s how to set up
cowpatch for local development.
Download a copy of
$ poetry install
git(or similar) to create a branch for local development and make your changes:
$ git checkout -b name-of-your-bugfix-or-feature
When you’re done making changes, check that your changes conform to any code formatting requirements and pass any tests.
Commit your changes and open a pull request.
Pull Request Guidelines
Before you submit a pull request, check that it meets these guidelines:
The pull request should include additional tests if appropriate.
If the pull request adds functionality, the docs should be updated.
The pull request should work for all currently supported operating systems and versions of Python (a subset of these will be checked with Github actions).
Code of Conduct
Please note that the
cowpatch project is released with a
Code of Conduct. By contributing to this project you agree to abide by its terms.