Contributing code via pull requests

While issue reporting is valuable, we strongly encourage users who are inclined to do so to submit patches for new or existing issues via pull requests. This is particularly the case for simple fixes, such as typos or tweaks to documentation, which do not require a heavy investment of time and attention.

Contributors are also encouraged to contribute new code to enhance ArviZ’s functionality, also via pull requests. Please consult the ArviZ documentation to ensure that any new contribution does not strongly overlap with existing functionality and open a “Feature Request” issue before starting to work on the new feature.

Steps before starting work

Before starting work on a pull request double-check that no one else is working on the ticket in both issue tickets and pull requests.

ArviZ is a community-driven project and always has multiple people working on it simultaneously. These guidelines define a set of rules to ensure that we all make the most of our time and we don’t have two contributors working on the same changes. Let’s see what to do when you encounter the following scenarios:

If an issue ticket exists

If an issue exists check the ticket to ensure no one else has started working on it. If you are first to start work, comment on the ticket to make it evident to others. If the comment looks old or abandoned leave a comment asking if you may start work.

If an issue ticket doesn’t exist

Open an issue ticket for the issue and state that you’ll be solving the issue with a pull request. Optionally create a pull request and add [WIP] in the title to indicate Work in Progress.

In the event of a conflict

In the event of two or more people working on the same issue, the general precedence will go to the person who first commented on the issue. If no comments it will go to the first person to submit a PR for review. Each situation will differ though, and the core contributors will make the best judgment call if needed.

If the issue ticket has someone assigned to it

If the issue is assigned then precedence goes to the assignee. However, if there has been no activity for 2 weeks from the assignment date, the ticket is open for all again and can be unassigned.

Development process - summary

The preferred workflow for contributing to ArviZ is to fork the GitHub repository, clone it to your local machine, and develop on a feature branch. the details of this process are listed on Pull request checklist. For a detailed description of the recommended development process, see Developer Guide.

Code Formatting

For code generally follow the TensorFlow’s style guide or the Google style guide. Both more or less follow PEP 8.

Final formatting is done with black.

Docstring formatting and type hints

Docstrings should follow the numpy docstring guide. Extra guidance can also be found in pandas docstring guide. Please reasonably document any additions or changes to the codebase, when in doubt, add a docstring.

The different formatting and aim between numpydoc style type description and type hints should be noted. numpydoc style targets docstrings and aims to be human readable whereas type hints target function definitions and .pyi files and aim to help third party tools such as type checkers or IDEs. ArviZ does not require functions to include type hints however contributions including them are welcome.

Documentation for user facing methods

If changes are made to a method documented in the ArviZ API Guide please consider adding inline documentation examples. You can refer to az.plot_posterior for a good example.


Section in construction


  1. Fork the project repository by clicking on the ‘Fork’ button near the top right of the main repository page. This creates a copy of the code under your GitHub user account.

  2. Clone your fork of the ArviZ repo from your GitHub account to your local disk.

    $ git clone<your GitHub handle>/arviz.git
    $ git clone<your GitHub handle>/arviz.git
  3. Navigate to your arviz directory and add the base repository as a remote:

    $ cd arviz
    $ git remote add upstream
    $ cd arviz
    $ git remote add upstream
  4. Create a feature branch to hold your development changes:

    $ git checkout -b my-feature


    Always create a new feature branch before making any changes. Make your chnages in the feature branch. It’s good practice to never routinely work on the main branch of any repository.

  5. Project requirements are in requirements.txt, and libraries used for development are in requirements-dev.txt. To set up a development environment, you may (probably in a virtual environment) run:

    $ pip install -r requirements.txt
    $ pip install -r requirements-dev.txt
    $ pip install -r requirements-docs.txt  # to generate docs locally

    Alternatively, for developing the project in Docker, there is a script to setup the Docker environment for development. See Developing in Docker.

  6. Develop the feature on your feature branch. Add your changes using git commands, git add and then git commit, like:

    $ git add modified_files
    $ git commit -m "commit message here"

    to record your changes locally. After committing, it is a good idea to sync with the base repository in case there have been any changes:

    $ git fetch upstream
    $ git rebase upstream/main

    Then push the changes to your GitHub account with:

    $ git push -u origin my-feature
  7. Go to the GitHub web page of your fork of the ArviZ repo. Click the ‘Pull request’ button to send your changes to the project’s maintainers for review. This will send an email to the committers.

Pull request checklist

We recommend that your contribution complies with the following guidelines before you submit a pull request:

  • If your pull request addresses an issue, please use the pull request title to describe the issue and mention the issue number in the pull request description. This will make sure a link back to the original issue is created.

  • All public methods must have informative docstrings with sample usage when appropriate.

  • Please prefix the title of incomplete contributions with [WIP] (to indicate a work in progress). WIPs may be useful to (1) indicate you are working on something to avoid duplicated work, (2) request a broad review of functionality or API, or (3) seek collaborators.

  • All other tests pass when everything is rebuilt from scratch. See Developing in Docker for information on running the test suite locally.

  • When adding additional plotting functionality, provide at least one example script in the arviz/examples/ folder. Have a look at other examples for reference. Examples should demonstrate why the new functionality is useful in practice and, if possible, compare it to other methods available in ArviZ.

  • Added tests follow the pytest fixture pattern.

  • Documentation and high-coverage tests are necessary for enhancements to be accepted.

  • Documentation follows Numpy style guide.

  • Run any of the pre-existing examples in docs/source/notebooks that contain analyses that would be affected by your changes to ensure that nothing breaks. This is a useful opportunity to not only check your work for bugs that might not be revealed by unit test, but also to show how your contribution improves ArviZ for end users.

  • If modifying a plot, render your plot to inspect for changes and copy image in the pull request message on Github.

You can also check for common programming errors with the following tools:

  • Save plots as part of tests. Plots will be saved to a directory named test_images by default.

    $ pytest arviz/tests/base_tests/<name of test>.py --save
  • Optionally save plots to a user named directory. This is useful for comparing changes across branches.

    $ pytest arviz/tests/base_tests/<name of test>.py --save user_defined_directory
  • Code coverage cannot decrease. Coverage can be checked with pytest-cov package:

    $ pip install pytest pytest-cov coverage
    $ pytest --cov=arviz --cov-report=html arviz/tests/
  • Your code has been formatted with black with a line length of 100 characters.

    $ pip install black
    $ black arviz/ examples/ asv_benchmarks/
  • Your code passes pylint

    $ pip install pylint
    $ pylint arviz/
  • No code style warnings, check with:

    $ ./scripts/

Running the benchmark tests

To run the benchmark tests do the following:

$ pip install asv
$ cd arviz
$ asv run

This guide was derived from the scikit-learn guide to contributing.