Contributions are welcome, and they are greatly appreciated! Every little bit helps, and credit will always be given.


To set up for local development:

$ git clone
$ cd pyinaturalist
$ pip install -Ue ".[dev]"
$ # Optional but recommended:
$ pre-commit install --config .github/pre-commit.yml

Contribution Guidelines


We use Sphinx, and the references page is automatically generated thanks to sphinx.ext.autodoc and sphinx_autodoc_typehints extensions. All functions / methods / classes should have proper docstrings.

To build the docs locally:

$ make -C docs html

To preview:

# MacOS:
$ open docs/_build/index.html
# Linux:
$ xdg-open docs/_build/index.html

Documentation is automatically built by ReadTheDocs whenever code is merged into either master or dev:

For any new or changed behavior, add a brief high-level summary to This isn’t needed for internal changes (tests, other docs, refactoring, etc.).


We use the pytest framework for unit testing. Just run the pytest command to run locally.

We also use tox to test multiple python versions. Use the tox command to run locally. This is also run by GitHub Actions on all pull requests.

Type Annotations

All parameters and return values should have type annotations, which will be checked by mypy and will show up in the documentation.

Formatting, Linting, Type Checking, Etc.

Code checking and formatting tools used include:

All of these will be run by GitHub Actions on pull requests.

Pre-Commit Hooks

Optionally, there is included config to easily set these up to run as a pre-commit hook:

pre-commit install --config .github/pre-commit.yml

This can save you some time in that it will show you errors immediately rather than waiting for CI jobs to complete. You can disable these hooks at any time with:

pre-commit uninstall

Pull Requests

Here are some general guidelines for submitting a pull request:

  • If the changes are trivial, just briefly explain the changes in the PR description.

  • Otherwise, please submit an issue describing the proposed change prior to submitting a PR.

  • Make sure the code is tested, annotated and documented as described above.

  • Submit the PR to be merged into the dev branch.


For maintainers:

Releases are based on git tags. GitHub Actions will build and deploy packages to PyPi on tagged commits on the master branch. Release steps:

  • Update the version in pyinaturalist/

  • Update the release notes in

  • Merge changes into the master branch

  • Push a new tag, e.g.: git tag v0.1 && git push origin --tags

  • This will trigger a deployment. Verify that this completes successfully and that the new version can be installed from pypi with pip install

Types of Contributions

You can contribute in many ways:

Report Bugs

Report bugs at

If you are reporting a bug, please include:

  • Your operating system name and version.

  • Any details about your local setup that might be helpful in troubleshooting.

  • Detailed steps to reproduce the bug.

Fix Bugs

Look through the GitHub issues for bugs. Anything tagged with “bug” is open to whoever wants to implement it.

Implement Features

Look through the GitHub issues for features. Anything tagged with “feature” is open to whoever wants to implement it.

Write Documentation

pyinaturalist could always use more documentation, whether as part of the official pyinaturalist docs, in docstrings, or even on the web in blog posts, articles, and such.

Submit Feedback

The best way to send feedback is to create an issue

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 :)