Guidelines for Contributing
As a scientific community-driven software project, ArviZ welcomes contributions from interested individuals or groups. These guidelines are provided to give potential contributors information to make their contribution compliant with the conventions of the ArviZ project, and maximize the probability of such contributions to be merged as quickly and efficiently as possible.
There are 4 main ways of contributing to the ArviZ project (in descending order of difficulty or scope):
- Adding new or improved functionality to the existing codebase
- Fixing outstanding issues (bugs) with the existing codebase. They range from low-level software bugs to higher-level design problems.
- Contributing or improving the documentation (
docs) or examples (
- Submitting issues related to bugs or desired enhancements
We appreciate being notified of problems with the existing ArviZ code. We prefer that issues be filed the on Github Issue Tracker, rather than on social media or by direct email to the developers.
Please verify that your issue is not being currently addressed by other issues or pull requests by using the GitHub search tool to look for key words in the project issue tracker.
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.
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.
Docstrings should follow the numpy docstring guide Please reasonably document any additions or changes to the codebase, when in doubt, add a docstring.
Documentation for user facing methods
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.
Clone your fork of the ArviZ repo from your GitHub account to your local disk, and add the base repository as a remote:
$ git clone email@example.com:<your GitHub handle>/arviz.git $ cd arviz $ git remote add upstream firstname.lastname@example.org:arviz-devs/arviz.git
featurebranch to hold your development changes:
$ git checkout -b my-feature
Always use a
featurebranch. It's good practice to never routinely work on the
masterbranch of any repository.
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
Alternatively, there is a script to create a docker environment for development. See: Developing in Docker.
Develop the feature on your feature branch. Add changed files using
git addand then
$ git add modified_files $ git commit
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/master
Then push the changes to your GitHub account with:
$ git push -u origin my-feature
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 recommended 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 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 functionality, provide at least one example script or Jupyter Notebook 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/notebooksthat 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 save to a directory named test_images by default
$ pytest arviz/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/<name of test>.py --save user_defined_directory
Code with good test coverage (at least 80%), check with:
$ pip install pytest pytest-cov coverage $ pytest --cov=arviz arviz/tests/<name of test>.py
Your code has been formatted with black with a line length of 100 characters. Note that black only runs in Python 3.6
$ pip install black $ black arviz/
Your code passes pylint
$ pip install pylint $ pylint arviz/
No code style warnings, check with:
Developing in Docker
We have provided a Dockerfile which helps for isolating build problems, and local development.
Install Docker for your operating system, clone this repo, then
./scripts/start_container.sh. This should start a local docker container called
as well as a
jupyter notebook server running on port 8888. The
notebook should be opened in your browser automatically (you can disable this by passing
--no-browser). The repo will be running the code from your local copy of
so it is good for development.
You may also use it to run the test suite, with
$ docker exec -it arviz bash # logon to the container $ cd ~/arviz $ . ./scripts/test.sh # takes a while!
This should be quite close to how the tests run on TravisCI.
If the container was started without opening the browser, you need the notebook instances token to work with the notebook. This token can be accessed with
docker exec -it arviz jupyter notebook list