Contributing to ArviZ#
Welcome#
Welcome to the ArviZ project! If you’re reading this guide, that probably means you’d like to get involved and start contributing to the project. ArviZ is a multi-language open-source project that provides tools for exploratory analysis of Bayesian models. The package includes functions for posterior analysis, data storage, sample diagnostics, model checking, and comparison.
As a scientific, community-driven, open-source software project, we welcome contributions from interested individuals or groups. The guidelines specified in this document can help new contributors make their contributions compliant with the conventions of the ArviZ python library, and maximize the probability of such contributions being merged as quickly and as efficiently as possible.
All kinds of contributions to ArviZ, either on its codebase, its documentation, or its community are valuable and we appreciate your help. We constantly encourage contributors (not only those contributing code) to become core contributors and participate in ArviZ governance. This repository has a historical log of contributor nominations.
Before you begin#
Before contributing to ArviZ, please make sure to read and observe the Code of Conduct.
Communication#
Contact us on Gitter if you want to contribute to the project but you are not sure where you can contribute or how to start.
Choosing a contribution type#
Historically, the most common way of contributing to the project is sending pull requests on the main ArviZ Github repository, but there are many other ways to help the project.
This section provides an overview of common contribution types to ArviZ along with reasons why different contributors choose them and how that benefits both them and the project. If you prefer video instead of written form, jump to the next section: Contributing to ArviZ webinar for a recording of an ArviZ core contributor on both technical and social aspects of contributing to the library.
You can contribute to ArviZ in the following ways:
Create an issue#
Submit issues for existing bugs or desired enhancements. Check Issue reports for details on how to write an issue.
By submitting an issue, you alert the ArviZ team about problems you are facing. One of the main tenets of open source is giving the users the freedom to use the software as they like, without restrictions. This means that open source projects always end up having uses the developers couldn’t have imagined. Issue reports can therefore let the team know about uses of ArviZ we hadn’t initially considered and also for things that were already taken into account signal how much use the different parts of the codebase are getting, informing prioritization of work.
Issue reports also serve as a register of tasks to work on for people interested in contributing to ArviZ who know they want to contribute code but don’t know where to start.
Issue triaging#
Helping to manage or triage the open issues can be a great contribution and a great opportunity to learn about the various areas of the project. You can triage existing issues to make them clear and/or provide temporary workarounds for them.
Issue triaging brings submitting issues to the next level. Issues by themselves are hard to keep track of, and sometimes they even increase faster than we can fix them. All while some of these end up outdated but are still kept open because we don’t have the capacity to check all of them regularly. For work on an issue to actually happen the issue needs to be clear and easily reproduceable. Going over issues and trying to reproduce them is a great way to become more familiar with the library.
In addition, categorizing the issues also makes the issue list much easier to work with, both for developers and new contributors. We can indicate issues that can’t be worked on yet because more discussion is needed, issues that can be a good first code related contribution, or issues that can’t be reproduced.
Translate ArviZ website#
You can translate our website to languages other than English.
Being able to contribute and interact with project resources in one’s native language reduces the barriers to participation and helps feel a sense of belonging on that community. Moreover, people reading in their native language are faster and less prone to errors.
Review PRs#
Review pull requests to ensure that the contributions are well tested and documented. For example, you can check if the documentation renders correctly and has no typos or mistakes.
We believe reviewing PRs is one of the best ways to learn about the codebase in depth. Core contributors are also expected to review the work of the rest of contributors, so it can also be a way to get a head start on joining the team and preparing for the core contributor role.
Moreover, developer time is usually one of the most scarce assets of a project. Especially for PRs submitted by newish contributors, having a first review pass by a recurrent contributor or even an experienced user who tests their changes can be extremely helpful; they get feedback faster and more extensive.
Write documentation#
You can contribute to ArviZ’s documentation by either creating new content or editing existing content. For instance, you can add new ArviZ examples. To get involved with the documentation:
Familiarize yourself with the documentation content structure and the tool chain involved in creating the website.
Understand the basic workflow for opening a pull request and reviewing changes.
Work on your content.
Build your documentation and preview the doc changes.
Support outreach initiatives#
Support ArviZ outreach initiatives such as writing blog posts, case studies, getting people to use ArviZ at your company or university, etc.
Make changes in the code#
Fix outstanding issues (bugs) in the existing codebase. The issue can range from low-level software bugs to high-level design problems. You can also add new features to the codebase or improve the existing functionality. To fix bugs or add new features, do the following:
Familiarize yourself with the guidelines before starting your work.
Understand the development process and code conventions.
Understand the basic workflow for opening a pull request and reviewing changes.
Review and test your code.