Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.
You can contribute in many ways:
Report bugs at https://github.com/jessemyers/cheddar/issues.
If you are reporting a bug, please include:
Look through the GitHub issues for bugs. Anything tagged with “bug” is open to whoever wants to implement it.
Look through the GitHub issues for features. Anything tagged with “feature” is open to whoever wants to implement it.
cheddar could always use more documentation, whether as part of the official cheddar docs, in docstrings, or even on the web in blog posts, articles, and such.
The best way to send feedback is to file an issue at https://github.com/jessemyers/cheddar/issues.
If you are proposing a feature:
Ready to contribute? Here’s how to set up cheddar for local development.
Fork the cheddar repo on GitHub.
Clone your fork locally:
$ git clone email@example.com:your_name_here/cheddar.git
Install your local copy into a virtualenv. this is how you set up your fork for local development:
$ virtualenv venv $ source venv/bin/activate $ python setup.py develop
Create a branch for local development:
$ git flow feature start name-of-your-bugfix-or-feature
Now you can make your changes locally.
5. When you’re done making changes, check that your changes pass flake8 and the tests, including testing other Python versions with tox:
$ flake8 cheddar tests $ python setup.py test $ tox To get flake8 and tox, just pip install them into your virtualenv.
Commit your changes and push your branch to GitHub:
$ git add . $ git commit -m "Your detailed description of your changes." $ git flow feature finish name-of-your-bugfix-or-feature
Submit a pull request through the GitHub website.
Before you submit a pull request, check that it meets these guidelines:
Cheddar uses gitflow for its branch management.
Changes based off of develop will receive the least amount of skepticism.
Changes based off of a release branches (if one exists) will be considered, especially for small bug fixes relevant to the release. We are not likely to accept new features against release branches.
Changes based off of master or a prior release tag will be given the most skepticism. We may accept patches for major bugs against past releases, but would prefer to see such changes follow the normal git-flow process.
We will not accept new features based off of master.