So you're interested in contributing to marshmallow or one of our associated projects? That's awesome! We welcome contributions from anyone willing to work in good faith with other contributors and the community (see also our :doc:`code_of_conduct`).
To report a security vulnerability, please use the Tidelift security contact. Tidelift will coordinate the fix and disclosure.
…should all be reported on the Github Issue Tracker .
- Comment on some of marshmallow's open issues (especially those labeled "feedback welcome"). Share a solution or workaround. Make a suggestion for how a feature can be made better. Opinions are welcome!
- Improve the docs. For straightforward edits, click the ReadTheDocs menu button in the bottom-right corner of the page and click "Edit". See the :ref:`Documentation <contributing_documentation>` section of this page if you want to build the docs locally.
- If you think you've found a bug, open an issue.
- Contribute an :ref:`example usage <contributing_examples>` of marshmallow.
- Send a PR for an open issue (especially one labeled "help wanted"). The next section details how to contribute code.
- Fork marshmallow on Github.
$ git clone https://github.com/marshmallow-code/marshmallow.git $ cd marshmallow
- Install development requirements. It is highly recommended that you use a virtualenv. Use the following command to install an editable version of marshmallow along with its development requirements.
# After activating your virtualenv $ pip install -e '.[dev]'
- Install the pre-commit hooks, which will format and lint your git staged files.
# The pre-commit CLI was installed above $ pre-commit install --allow-missing-config
Marshmallow abides by the following branching model:
dev
- Current development branch. New features should branch off here.
X.Y-line
- Maintenance branch for release
X.Y
. Bug fixes should be sent to the most recent release branch. The maintainer will forward-port the fix todev
. Note: exceptions may be made for bug fixes that introduce large code changes.
Always make a new branch for your work, no matter how small. Also, do not put unrelated changes in the same branch or pull request. This makes it more difficult to merge your changes.
- Create a new local branch.
# For a new feature $ git checkout -b name-of-feature dev # For a bugfix $ git checkout -b fix-something 2.x-line
- Commit your changes. Write good commit messages.
$ git commit -m "Detailed commit message" $ git push origin name-of-feature
- Before submitting a pull request, check the following:
- If the pull request adds functionality, it is tested and the docs are updated.
- You've added yourself to
AUTHORS.rst
.
- Submit a pull request to
marshmallow-code:dev
or the appropriate maintenance branch. The CI build must be passing before your pull request is merged.
To run all tests:
$ pytest
To run formatting and syntax checks:
$ tox -e lint
(Optional) To run tests in all supported Python versions in their own virtual environments (must have each interpreter installed):
$ tox
Contributions to the documentation are welcome. Documentation is written in reStructuredText (rST). A quick rST reference can be found here. Builds are powered by Sphinx.
To build the docs in "watch" mode:
$ tox -e watch-docs
Changes in the docs/ directory will automatically trigger a rebuild.
Have a usage example you'd like to share? A custom Field that others might find useful? Feel free to add it to the examples directory and send a pull request.