diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 49789ec581..bf718d5f03 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,296 +1,24 @@
-# 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 (`arviz/examples`)
-* Submitting issues related to bugs or desired enhancements
-
-This doc plus extra guidance is also available on [ArviZ documentation](https://arviz-devs.github.io/arviz/contributing/index.html)
-
-# Opening issues
-
-We appreciate being notified of problems with the existing ArviZ code. We prefer that issues be filed the on [Github Issue Tracker](https://github.com/arviz-devs/arviz/issues), 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](https://arviz-devs.github.io/arviz/)
-to ensure that any new contribution does not strongly overlap with existing functionality.
-
-## Steps before starting work
-Before starting a work on a pull request double check that no one else is working on the ticket in both issue tickets and pull requests.
-
-### If an issue ticket exists
-If an issue exists check the ticket to ensure no one else has started work. If 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 in 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 judgement 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 assignment date the ticket is open for all again and can be unassigned.
-
-## Making the pull request
-The preferred workflow for contributing to ArviZ is to fork
-the [GitHub repository](https://github.com/arviz-devs/arviz/), clone it to your local machine, and develop on a feature branch.
-
-For more instructions see the
-[Pull request checklist](#pull-request-checklist)
-
-
-### Code Formatting
-For code generally follow the
-[TensorFlow's style guide](https://www.tensorflow.org/community/contribute/code_style)
-or the [Google style guide](https://github.com/google/styleguide/blob/gh-pages/pyguide.md)
-Both more or less follows PEP 8.
-
-Final formatting is done with [black](https://github.com/ambv/black).
-For more detailed steps on a typical development workflow see the
-[Pull request checklist](#pull-request-checklist)
-
-
-### Docstring formatting and type hints
-Docstrings should follow the
-[numpy docstring guide](https://numpydoc.readthedocs.io/en/latest/format.html).
-Extra guidance can also be found in
-[pandas docstring guide](https://pandas.pydata.org/pandas-docs/stable/development/contributing_docstring.html).
-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](https://docs.python.org/3/library/typing.html)
-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](https://numpydoc.readthedocs.io/en/latest/format.html)
-please consider adding inline documentation examples.
-`az.plot_posterior` is a particularly
-[good example](https://arviz-devs.github.io/arviz/api/generated/arviz.plot_posterior.html#arviz.plot_posterior).
-
-
-## Steps
-
-1. Fork the [project repository](https://github.com/arviz-devs/arviz/) 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, and add the base repository as a remote:
-
- ```bash
- $ git clone git@github.com:/arviz.git
- $ cd arviz
- $ git remote add upstream git@github.com:arviz-devs/arviz.git
- ```
-
-3. Create a ``feature`` branch to hold your development changes:
-
- ```bash
- $ git checkout -b my-feature
- ```
-
- Always use a ``feature`` branch. It's good practice to never routinely work on the ``main`` branch of any repository.
-
-4. 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](https://docs.python-guide.org/dev/virtualenvs/)) run:
-
- ```bash
- $ 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](#developing-in-docker).
-
-Note: Building the documentation locally requires saving Bokeh plots as
-images. To do this, bokeh needs some [extra dependencies](https://docs.bokeh.org/en/latest/docs/user_guide/export.html#exporting-plots)
-that can not be installed with pip and are therefore not in
-``requirements-dev.txt``. To build documentation locally without having to
-install these extra dependencies, Docker can be used. See: [Building documentation with Docker](#building-documentation-with-docker)
-
-5. Develop the feature on your feature branch. Add changed files using ``git add`` and then ``git commit`` files:
-
- ```bash
- $ 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:
- ```bash
- $ git fetch upstream
- $ git rebase upstream/main
- ```
-
- Then push the changes to your GitHub account with:
-
- ```bash
- $ git push -u origin my-feature
- ```
-
-6. 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 broad review of functionality or API, or (3) seek collaborators.
-
-* All other tests pass when everything is rebuilt from scratch. See
-[Developing in Docker](#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](https://docs.pytest.org/en/latest/fixture.html#fixture)
-
-* 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 save to a directory named test_images by default
-
- ```bash
- $ pytest arviz/tests/base_tests/.py --save
- ```
-
-* Optionally save plots to a user named directory. This is useful for comparing changes across branches
-
- ```bash
- $ pytest arviz/tests/base_tests/.py --save user_defined_directory
- ```
-
-
-* Code coverage **cannot** decrease. Coverage can be checked with **pytest-cov** package:
-
- ```bash
- $ pip install pytest pytest-cov coverage
- $ pytest --cov=arviz --cov-report=html arviz/tests/
- ```
-
-* Your code has been formatted with [black](https://github.com/ambv/black) with a line length of 100 characters. Note that black only runs in Python 3.6+
-
- ```bash
- $ pip install black
- $ black arviz/ examples/ asv_benchmarks/
- ```
-
-* Your code passes pylint
-
- ```bash
- $ pip install pylint
- $ pylint arviz/
- ```
-
-* No code style warnings, check with:
-
- ```bash
- $ ./scripts/lint.sh
- ```
-
-## Developing in Docker
-
-We have provided a Dockerfile which helps for isolating build problems, and local development.
-Install [Docker](https://www.docker.com/) for your operating system, clone this repo. Docker will generate an environment with your local copy of `arviz` with all the packages in Dockerfile.
-
-### container.sh & container.ps1
-
-Predefined docker commands can be run with a `./scripts/container.sh` (on Linux and macOS)
-and with `./scripts/container.ps1`. The scripts enables developer easily to call predefined docker commands.
-User can use one or multiple flags.
-
-They are executed on the following order: clear-cache, build, test, docs, shell, notebook, lab
-
- $ ./scripts/container.sh --clear-cache
- $ ./scripts/container.sh --build
-
- $ ./scripts/container.sh --test
- $ ./scripts/container.sh --docs
- $ ./scripts/container.sh --shell
- $ ./scripts/container.sh --notebook
- $ ./scripts/container.sh --lab
-
-
- $ powershell.exe -File ./scripts/container.ps1 --clear-cache
- $ powershell.exe -File ./scripts/container.ps1 --build
-
- $ powershell.exe -File ./scripts/container.ps1 --test
- $ powershell.exe -File ./scripts/container.ps1 --docs
- $ powershell.exe -File ./scripts/container.ps1 --shell
- $ powershell.exe -File ./scripts/container.ps1 --notebook
- $ powershell.exe -File ./scripts/container.ps1 --lab
-
-### Testing in Docker
-Testing the code using docker consists of executing the same file 3 times (you may need root privileges to run it).
-First run `./scripts/container.sh --clear-cache`. Then run `./scripts/container.sh --build`. This starts a local docker image called `arviz`. Finally run the tests with `./scripts/container.sh --test`. This should be quite close to how the tests run on TravisCI.
-
-NOTE: If you run into errors due to `__pycache__` files (i.e. while testing in
-docker after testing locally or installing with pip after testing with
-docker), try running `./scripts/container.sh --clear-cache` before the errored
-command.
-
-### Using the Docker image interactively
-Once the Docker image is built with `./scripts/container.sh --build`, interactive containers can also be run. Therefore, code can be edited and executed using the docker container, but modifying directly the working directory of the host machine.
-
-To start a bash shell inside Docker, run:
-
- $ docker run --mount type=bind,source="$(pwd)",target=/opt/arviz/ -it arviz bash
-
-and for Windows, use %CD% on cmd.exe and $pwd.Path on powershell.
-
- $ docker run --mount type=bind,source=%CD%,target=/opt/arviz/ -it arviz bash
-
-Alternatively, to start a jupyter notebook, there are two steps, first run:
-
- $ docker run --mount type=bind,source="$(pwd)",target=/opt/arviz/ --name jupyter-dock -it -d -p 8888:8888 arviz
- $ docker exec jupyter-dock bash -c "pip install jupyter"
- $ docker exec -it jupyter-dock bash -c "jupyter notebook --ip 0.0.0.0 --no-browser --allow-root"
-
-and the same on Windows
-
- $ docker run --mount type=bind,source=%CD%,target=/opt/arviz/ --name jupyter-dock -it -d -p 8888:8888 arviz
- $ docker exec jupyter-dock bash -c "pip install jupyter"
- $ docker exec -it jupyter-dock bash -c "jupyter notebook --ip 0.0.0.0 --no-browser --allow-root"
-
-This will output something similar to `http://( or ):8888/?token=`, and can be accessed at `http://localhost:8888/?token=`.
-
-### Building documentation with Docker
-The documentation can be build with Docker by running `./scripts/container.sh
---docs`. The docker image contains by default all dependencies needed
-for building the documentation. After having build the docs in the Docker
-container, they can be checked at `doc/build` and viewed in the browser from `doc/build/index.html`. To rebuild the docs re-run `./scripts/container.sh --docs` after making changes.
-
-## 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](https://github.com/scikit-learn/scikit-learn/blob/main/CONTRIBUTING.md)**
+# Contributing to ArviZ
+This document outlines only the most common contributions.
+Please see the [Contributing guide](https://arviz-devs.github.io/arviz/contributing/index.html)
+on our documentation for a better view of how can you contribute to ArviZ.
+We welcome a wide range of contributions, not only code!
+
+## Reporting issues
+If you encounter any bug or incorrect behaviour while using ArviZ,
+please report an issue to our [issue tracker](https://github.com/arviz-devs/arviz/issues).
+Please include any supporting information, in particular the version of
+ArviZ that you are using.
+The issue tracker has several templates available to help in writing the issue
+and including useful supporting information.
+
+## Contributing code
+Thanks for your interest in contributing code to ArviZ!
+
+* If this is your first time contributing to a project on GitHub, please read through our step by step guide to contributing to ArviZ
+* If you have contributed to other projects on GitHub you can go straight to our [development workflow]()
+
+### Adding new features
+If you are interested in adding a new feature to ArviZ,
+first submit an issue using the "Feature Requrest" label for the community
+to discuss its place and implementation within ArviZ.
diff --git a/GOVERNANCE.md b/GOVERNANCE.md
index 614783acd3..c4c5291722 100644
--- a/GOVERNANCE.md
+++ b/GOVERNANCE.md
@@ -1,7 +1,6 @@
# Main Governance Document
-The Project
-===========
+## The Project
The ArviZ Project (The Project) is an open source software project
affiliated with the 501c3 NumFOCUS Foundation. The goal of The Project is to
@@ -34,7 +33,7 @@ The Project is formally affiliated with the 501c3 NumFOCUS Foundation
([http://numfocus.org](http://numfocus.org)), NumFOCUS is the
only legal entity that has a formal relationship with the project.
-### Governance
+## Governance
This section describes the governance and leadership model of The Project.
@@ -58,20 +57,55 @@ the formalization of what we are already doing, rather than a change in
direction.
-Community Architecture
------------------------
+## Community Architecture
-* 7 Person steering council
-* Core Contributors (of which Council members are also a part of)
* General Contributors
+* Core Contributors (of which Council members are also a part of)
+* 7 Person steering council (Random Variables Council)
Anyone working with ArviZ has the responsibility to personally uphold
the Code of Conduct. Core Contributors have the additional responsibility
of _enforcing_ the Code of Conduct to maintain a safe community.
+## Core Contributors
+Core Contributors are those who have provided consistent and meaningful contributions to ArviZ.
+These can be, but are not limited to, code contributions, community contributions, tutorial
+development etc. Core Contributors will be given the ability to manage the ArviZ GitHub
+repository, including code merges to main. This does not necessarily mean Core Contributors
+must submit code, but more so signifies trust with the project as a whole.
+
+### Core Contributor Responsibilities
+* Enforce code of conduct
+* Maintain a check against Council
+
+### Core Contributor Nominations and Confirmation Process
+Current Core Contributors can nominate candidates to become Core Contributors by
+requesting so in a GitHub issue. If nominated candidates accept their nomination
+(explicit comment approving nomination on the issue or "thumbs-up" emoji on the same issue),
+then they can be considered by the Council: on the first of the month following a
+nomination, the Council will vote on each nominee using the process above.
+
+Voting will be private with results published on the issue ticket. In the case of a
+rejection, results must include the reasons behind the decision (e.g. the time since
+starting to contribute is deemed too short for now). The candidate
+would then have to wait 3 months to be considered again.
+
+### Current Core Contributors
+* Oriol Abril-Pla (@OriolAbril)
+* Agustina Arroyuelo (@agustinaarroyuelo)
+* Alex Andorra (@AlexAndorra)
+* Seth Axen (@sethaxen)
+* Colin Carroll (@ColCarroll)
+* Piyush Gautam (@percygautam)
+* Robert P. Goldman (@rpgoldman)
+* Ari Hartikainen (@ahartikainen)
+* Ravin Kumar (@canyon289)
+* Osvaldo Martin (@aloctavodia)
+* Mitzi Morris (@mitzimorris)
+* Du Phan (@fehiepsi)
+* Aki Vehtari (@avehtari)
-Random Variables Council
-------------------------
+## Random Variables Council
The Project will have a Steering Council that consists of Core Contributors
who have produced contributions that are substantial in quality and quantity,
and sustained over at least one year. The overall role of the Council is to
@@ -103,6 +137,19 @@ responsibilities, but the council as a whole must jointly make these decisions.
In other words, Council Members are first and foremost Core Contributors, but only
when needed they can collectively make decisions for the health of the project.
+### Current Random Variables Council members
+The current RV Council members are:
+
+* Oriol Abril-Pla (@OriolAbril)
+* Alex Andorra (@AlexAndorra)
+* Seth Axen (@sethaxen)
+* Colin Carroll (@ColCarroll)
+* Ari Hartikainen (@ahartikainen)
+* Ravin Kumar (@canyon289)
+* Osvaldo Martin (@aloctavodia)
+
+The election record can be found at [elections/ArviZ_2020.md](https://github.com/arviz-devs/arviz/blob/main/elections/ArviZ_2020.md)
+
### Council Decision Making Process
By and large we expect the decisions in ArviZ to be made _ad hoc_ and require little formal
coordination and with the community at large. However, for controversial proposals and
@@ -253,41 +300,3 @@ Voting for first election is restricted to establish stable governance, and to d
* In the first year, the council must determine voting eligibility for future elections between two criteria:
* Core contributors
* The contributing community at large
-
-### Core Contributors
-Core Contributors are those who have provided consistent and meaningful contributions to ArviZ.
-These can be, but are not limited to, code contributions, community contributions, tutorial
-development etc. Core Contributors will be given the ability to manage the ArviZ GitHub
-repository, including code merges to main. This does not necessarily mean Core Contributors
-must submit code, but more so signifies trust with the project as a whole.
-
-#### Core Contributor Responsibilities
-* Enforce code of conduct
-* Maintain a check against Council
-
-#### Core Contributor Nominations and Confirmation Process
-Current Core Contributors can nominate candidates to become Core Contributors by
-requesting so in a GitHub issue. If nominated candidates accept their nomination
-(explicit comment approving nomination on the issue or "thumbs-up" emoji on the same issue),
-then they can be considered by the Council: on the first of the month following a
-nomination, the Council will vote on each nominee using the process above.
-
-Voting will be private with results published on the issue ticket. In the case of a
-rejection, results must include the reasons behind the decision (e.g. the time since
-starting to contribute is deemed too short for now). The candidate
-would then have to wait 3 months to be considered again.
-
-#### Current Core Contributors
-* Oriol Abril-Pla (@OriolAbril)
-* Agustina Arroyuelo (@agustinaarroyuelo)
-* Alex Andorra (@AlexAndorra)
-* Seth Axen (@sethaxen)
-* Colin Carroll (@ColCarroll)
-* Piyush Gautam (@percygautam)
-* Robert P. Goldman (@rpgoldman)
-* Ari Hartikainen (@ahartikainen)
-* Ravin Kumar (@canyon289)
-* Osvaldo Martin (@aloctavodia)
-* Mitzi Morris (@mitzimorris)
-* Du Phan (@fehiepsi)
-* Aki Vehtari (@avehtari)
diff --git a/README.md b/README.md
index b7fdae0457..87d8d49b26 100644
--- a/README.md
+++ b/README.md
@@ -195,4 +195,4 @@ can be found in the [Code of Conduct](https://github.com/arviz-devs/arviz/blob/m
ArviZ is a non-profit project under NumFOCUS umbrella. If you want to support ArviZ financially, you can donate [here](https://numfocus.org/donate-to-arviz).
## Sponsors
-[](https://numfocus.org)
+[](https://numfocus.org)
diff --git a/doc/Makefile b/doc/Makefile
index d08092b085..4076e95d99 100644
--- a/doc/Makefile
+++ b/doc/Makefile
@@ -2,11 +2,11 @@
#
# You can set these variables from the command line.
-SPHINXOPTS =
-SPHINXBUILD = python -msphinx
+SPHINXOPTS = -b html
+SPHINXBUILD = sphinx-build
SPHINXPROJ = ArviZ
SOURCEDIR = source
-BUILDDIR = _build
+BUILDDIR = build
# Put it first so that "make" without argument is like "make help".
help:
diff --git a/doc/source/_static/images/bambi.png b/doc/source/_static/images/bambi.png
new file mode 100644
index 0000000000..d73a6f7b01
Binary files /dev/null and b/doc/source/_static/images/bambi.png differ
diff --git a/doc/source/about.rst b/doc/source/about.rst
deleted file mode 100644
index 40582602f7..0000000000
--- a/doc/source/about.rst
+++ /dev/null
@@ -1,46 +0,0 @@
-.. about:
-
-
-*****
-About
-*****
-
-
-Reporting Issues
-================
-
-To report an issue please use the `issue tracker `__.
-Please include any supporting information, in particular the version of ArviZ that you are using.
-
-
-Feature Requests
-================
-
-To request a feature please use the
-`issue tracker `__. and add the label "Feature Request"
-
-
-License
-=======
-
-`Apache License, Version
-2.0 `__
-
-
-Contributors
-============
-
-See the :ref:`Contributing page `
-
-Project governance
-==================
-
-Both the project `code of conduct `_
-and its `governance `_ can be found
-at GitHub.
-
-
-
-Donations
-=========
-ArviZ is a non-profit project under NumFOCUS umbrella. If you want to support ArviZ financially, you can donate `here `_.
diff --git a/doc/source/about_us.md b/doc/source/about_us.md
new file mode 100644
index 0000000000..46253db508
--- /dev/null
+++ b/doc/source/about_us.md
@@ -0,0 +1,141 @@
+(about_us)=
+
+# About us
+ArviZ is an open source project aiming to provide tools for Exploratory
+Analysis of Bayesian Models that do not depend on the inference library
+used. ArviZ brings together people from several probabilistic programming
+libraries and from multiple programming languages. ArviZ will always be
+free for everyone to use and released under the
+[Apache License](https://github.com/arviz-devs/arviz/blob/main/LICENSE)
+(Version 2.0).
+
+ArviZ is developed in the open on [GitHub](https://github.com/arviz-devs/arviz)
+with the input of the whole community and consensus of its core contributors.
+For more information about our governance approach, read our
+[Governance Document](https://github.com/arviz-devs/arviz/blob/main/GOVERNANCE.md).
+
+## Our team
+ArviZ is maintained and governed by an international group of core contributors, as defined
+by our governance. You can see our current team in the cards below, as well as
+in [our governance doc](https://github.com/arviz-devs/arviz/blob/main/GOVERNANCE.md#current-core-contributors).
+
+People interested in joining the project should read
+[this section](https://github.com/arviz-devs/arviz/blob/main/GOVERNANCE.md#core-contributors)
+of our governance doc.
+Those interested in contributing should instead refer to our {ref}`contributing_guide`.
+
+```{include} core_contributors.md
+```
+
+## Support ArviZ
+If you have found ArviZ useful in your work, research, or company, consider supporting the
+project in any of the ways described in this section.
+
+### Donate
+If you or your company have the means to do so,
+consider a donation to the project commensurate with your resources.
+Any amount helps! All donations will be used strictly to fund the development
+of ArviZ’s open source software, documentation, and community.
+
+ArviZ is a Sponsored Project of NumFOCUS, a 501(c)(3) nonprofit charity in the United States.
+NumFOCUS provides ArviZ with fiscal, legal, and administrative support to
+help ensure the health and sustainability of the project.
+Visit [numfocus.org](https://numfocus.org/) for more information.
+
+Donations to ArviZ are managed by NumFOCUS. For donors in the United States,
+your gift is tax-deductible to the extent provided by law.
+As with any donation, you should consult with your tax advisor about
+your particular tax situation.
+
+The ArviZ project will make the decisions on how to best use any funds received
+to serve the priorities outlined in our
+[Roadmap](https://github.com/arviz-devs/arviz/wiki/ArviZ-2021-roadmap).
+
+```{raw} html
+
+```
+
+### Cite
+If you use ArviZ in your scientific work, you can cite it using [](https://doi.org/10.21105/joss.01143)
+
+Here is the citation in BibTeX format
+
+```
+@article{arviz_2019,
+ doi = {10.21105/joss.01143},
+ url = {https://doi.org/10.21105/joss.01143},
+ year = {2019},
+ publisher = {The Open Journal},
+ volume = {4},
+ number = {33},
+ pages = {1143},
+ author = {Ravin Kumar and Colin Carroll and Ari Hartikainen and Osvaldo Martin},
+ title = {ArviZ a unified library for exploratory analysis of Bayesian models in Python},
+ journal = {Journal of Open Source Software}
+}
+```
+
+Please also consider citing ArviZ's {ref}`arviz-dependencies` and
+the inference library used to build and fit the model.
+
+### ArviZ for enterprise
+
+> ArviZ is now available as part of the Tidelift Subscription!
+
+Tidelift is working with ArviZ and the maintainers of thousands of other open source projects
+to deliver commercial support and maintenance for the open source dependencies
+you use to build your applications.
+Save time, reduce risk, and improve code health, while contributing financially to ArviZ.
+
+```{raw} html
+
+
+```
+
+#### Enterprise-ready open source software — managed for you
+
+The Tidelift Subscription is a managed open source subscription for application
+dependencies covering millions of open source projects across JavaScript, Python, Java,
+PHP, Ruby, .NET, and more. And now, your favorite probabilistic programming language is included in the Tidelift subscription!
+
+Your subscription includes:
+
+* **Security updates**: Tidelift’s security response team coordinates patches for new breaking security vulnerabilities and alerts immediately through a private channel, so your software supply chain is always secure.
+
+* **Licensing verification and indemnification**: Tidelift verifies license information to enable easy policy enforcement and adds intellectual property indemnification to cover creators and users in case something goes wrong. You always have a 100% up-to-date bill of materials for your dependencies to share with your legal team, customers, or partners.
+
+* **Maintenance and code improvement**: Tidelift ensures the software you rely on keeps working as long as you need it to work. Your managed dependencies are actively maintained and Tidelift recruits additional maintainers where required.
+
+* **Package selection and version guidance**: Tidelift helps you choose the best open source packages from the start—and then guides you through updates to stay on the best releases as new issues arise.
+
+* **Roadmap input**: Take a seat at the table with the creators behind the software you use. ArviZ core contributors and other Tidelift’s participating maintainers earn more income as our software is used by more subscribers, so we’re interested in knowing what you need.
+
+* **Tooling and cloud integration**: Tidelift works with GitHub, GitLab, BitBucket, and more. It supports every cloud platform (and other deployment targets, too).
+
+The end result? All of the capabilities you expect from commercial-grade software, for the full breadth of open source you use. That means less time grappling with esoteric open source trivia, and more time building your own applications — and your business.
+
+```{raw} html
+
+
+```
+
+## Sponsors
+[](https://numfocus.org)
diff --git a/doc/source/community.md b/doc/source/community.md
new file mode 100644
index 0000000000..91bad432d3
--- /dev/null
+++ b/doc/source/community.md
@@ -0,0 +1,106 @@
+# Community
+ArviZ is a community-driven open source project committed to host an open,
+inclusive and positive community. Read the
+[ArviZ Code of Conduct](https://github.com/arviz-devs/arviz/blob/main/CODE_OF_CONDUCT.md)
+for guidance on how to interact with each other and make the community thrive.
+
+Our main goal is to provide backend-agnostic tools for diagnostics and visualizations of Bayesian
+inference.
+
+We do this by:
+
+* Creating and maintaining the ArviZ library with functions for posterior analysis, data storage,
+ sample diagnostics, model checking, and comparison.
+* Creating social infrastructure through a welcoming and diverse community
+* Making the right data, tools and best practices more discoverable
+* Promoting advocacy for a culture of principled iterative modeling based on the Bayesian Workflow
+
+This page aims to gather resources related to Bayesian modeling and ArviZ from a variety of
+sources to work towards the 2nd and 3rd bullet points.
+This page covers how can someone participate of the ArviZ community (this someone could be you!),
+gives an overview of the ecosystem of Python libraries for Bayesian analysis and serves
+as a compilation for community resources around ArviZ.
+
+*But what is the ArviZ community?*
+The ArviZ community is a self-identifying group composed of probabilistic programming practitioners who,
+together, contribute to the technical and social infrastructure for open and reproducible research.
+Our specific focus is on Bayesian modeling and best practices that lower the barriers to working using
+a fully fledged Bayesian modeling workflow, as opposed to a rigid toolbox approach.
+
+Community members are people who use, cite and share use cases for ArviZ,
+write posts or give talks about using ArviZ,
+participate in issues to help define the roadmap and improve the project,
+or answer questions in any of the affine forums.
+
+This page is part of the Python ArviZ library and is therefore specific to Python,
+but the ArviZ community is not restricted to Python and in fact aims to act as a bridge
+between programming languages and encourage collaboration.
+
+## Participate online
+There are many alternatives and channels available to interact with other ArviZ users.
+
+To begin with, you may want to follow us on Twitter! We are [@arviz_devs](https://twitter.com/arviz_devs).
+It is the best way to be up to date with the latest developments and events related
+to ArviZ.
+
+### Gitter
+The chat at [Gitter](https://gitter.im/arviz-devs/community) is a great space
+to ask quick questions about ArviZ and to chat with other users and contributors.
+For longer questions, the Discourse forums listed below are probably a better platform.
+
+### Affine forums
+Many ArviZ contributors are also active in one of [PyMC3 Discourse](https://discourse.pymc.io/)
+or [Stan Discourse](https://discourse.mc-stan.org/) (and sometimes even in both!).
+
+## Conferences
+* [StanCon](https://mc-stan.org/events/)
+* [PyMCon](https://pymcon.com)
+
+# The Bayesian Python ecosystem
+In the last years, many libraries for Bayesian data analysis have been created,
+and there is a slight tendency towards more modular libraries. ArviZ plays
+an important role in this ecosystem both as the go-to library for visualization
+and diagnostics in Python for any and all PPLs and as a way to standardize and
+share the results of PPL libraries.
+
+The PPLs that integrate with ArviZ are:
+
+* PyMC3
+* Stan
+* MCX
+* Pyro/NumPyro
+* PyJAGS
+* TensorFlow Probability
+
+Moreover, there are other libraries that use ArviZ for visualization and diagnostics
+and/or that are compatible with `InfereceData` objects:
+
+* Bambi
+* corner.py
+
+# Community educational resources
+ArviZ is a transversal and backend agnostic project. One can use ArviZ with _any_ PPL,
+but one has to be used in order to have some data for ArviZ to analyze.
+This makes writing detailed and complete documentation for ArviZ complicated.
+This section aims to act as a compilation of community resources related to ArviZ
+that hopefully can bridge the gap. These can be books, case studies in the documentation of
+PPLs, personal blogs...
+
+Do you know of resources about ArviZ that are not listed here? Open an issue or a PR and
+let us know!
+
+## Books
+* Bayesian Modeling and Computation in Python: available soon
+* [Bayesian Analysis with Python](https://github.com/aloctavodia/BAP)
+* [Bayesian Data Analysis 3](http://www.stat.columbia.edu/~gelman/book/)
+
+## Podcasts
+* [Learning Bayesian Statistics](https://www.learnbayesstats.com/)
+* [dats'n'stats](https://www.pydata-podcast.com/)
+
+## Blogs and example compilations
+If you have a blog that has 2 or more posts tagged as "ArviZ", you can submit
+a pull request to add your blog to this list
+
+```{include} external_resources.md
+```
diff --git a/doc/source/conf.py b/doc/source/conf.py
index f0ed836a4d..59ec154742 100644
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -18,9 +18,8 @@
# documentation root, use os.path.abspath to make it absolute, like shown here.
#
import os
-import re
import sys
-from typing import Dict
+from typing import Dict, Any
sys.path.insert(0, os.path.dirname(os.path.dirname(os.path.dirname(os.path.abspath(__file__)))))
import arviz
@@ -88,7 +87,6 @@
myst_heading_anchors = 3
panels_add_bootstrap_css = False
-
# The base toctree document.
master_doc = "index"
@@ -141,7 +139,6 @@
# Theme options are theme-specific and customize the look and feel of a theme
# further. For a list of options available for each theme, see the
# documentation.
-
html_theme_options = {
"icon_links": [
{
@@ -164,6 +161,9 @@
"github_version": "main",
"doc_path": "doc/source/",
}
+html_sidebars : Dict[str, Any] = {
+ "community": []
+}
# Add any paths that contain custom static files (such as style sheets) here,
# relative to this directory. They are copied after the builtin static files,
@@ -171,10 +171,6 @@
# html_theme_path = sphinx_bootstrap_theme.get_html_theme_path()
html_static_path = ["_static", thumb_directory]
-# Custom sidebar templates, must be a dictionary that maps document names
-# to template names.
-# html_sidebars = {}
-
# use additional pages to add a 404 page
html_additional_pages = {
"404": "404.html",
diff --git a/doc/source/contributing/contributing.md b/doc/source/contributing/contributing.md
deleted file mode 100644
index 004f419c74..0000000000
--- a/doc/source/contributing/contributing.md
+++ /dev/null
@@ -1,2 +0,0 @@
-```{include} ../../../CONTRIBUTING.md
-```
diff --git a/doc/source/contributing/contributing_prs.md b/doc/source/contributing/contributing_prs.md
new file mode 100644
index 0000000000..9b7b3ff4d3
--- /dev/null
+++ b/doc/source/contributing/contributing_prs.md
@@ -0,0 +1,284 @@
+# 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](https://arviz-devs.github.io/arviz/)
+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 a 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 at the same time. This 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.
+
+### If an issue ticket exists
+If an issue exists check the ticket to ensure no one else has started work. If 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 in 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 judgement 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 assignment date the ticket is open for all again and can be unassigned.
+
+(dev_summary)=
+# Development process - summary
+The preferred workflow for contributing to ArviZ is to fork
+the [GitHub repository](https://github.com/arviz-devs/arviz/),
+clone it to your local machine, and develop on a feature branch.
+
+For some more instructions see the {ref}`pr_checklist`, for a detailed
+description of the recommended development process, see {ref}`developer_guide`
+
+## Code Formatting
+For code generally follow the
+[TensorFlow's style guide](https://www.tensorflow.org/community/contribute/code_style)
+or the [Google style guide](https://github.com/google/styleguide/blob/gh-pages/pyguide.md).
+Both more or less follow PEP 8.
+
+Final formatting is done with [black](https://github.com/ambv/black).
+
+
+## Docstring formatting and type hints
+Docstrings should follow the
+[numpy docstring guide](https://numpydoc.readthedocs.io/en/latest/format.html).
+Extra guidance can also be found in
+[pandas docstring guide](https://pandas.pydata.org/pandas-docs/stable/development/contributing_docstring.html).
+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](https://docs.python.org/3/library/typing.html)
+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](https://numpydoc.readthedocs.io/en/latest/format.html)
+please consider adding inline documentation examples.
+`az.plot_posterior` is a particularly
+{func}`good example `.
+
+## Tests
+Section in construction
+
+# Steps
+
+1. Fork the [project repository](https://github.com/arviz-devs/arviz/) 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, and add the base repository as a remote:
+
+ ```bash
+ $ git clone git@github.com:/arviz.git
+ $ cd arviz
+ $ git remote add upstream git@github.com:arviz-devs/arviz.git
+ ```
+
+3. Create a ``feature`` branch to hold your development changes:
+
+ ```bash
+ $ git checkout -b my-feature
+ ```
+
+ Always use a ``feature`` branch. It's good practice to never routinely work on the ``main`` branch of any repository.
+
+4. 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](https://docs.python-guide.org/dev/virtualenvs/)) run:
+
+ ```bash
+ $ pip install -r requirements.txt
+ $ pip install -r requirements-dev.txt
+ $ pip install -r requirements-docs.txt # to generate docs locally
+ ```
+
+ Alternatively, there is a script to create a docker environment for development.
+ See: {ref}`developing_in_docker`
+
+5. Develop the feature on your feature branch. Add changed files using ``git add`` and then ``git commit`` files:
+
+ ```bash
+ $ 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:
+ ```bash
+ $ git fetch upstream
+ $ git rebase upstream/main
+ ```
+
+ Then push the changes to your GitHub account with:
+
+ ```bash
+ $ git push -u origin my-feature
+ ```
+
+6. 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.
+
+(pr_checklist)=
+# 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 broad review of functionality or API, or (3) seek collaborators.
+
+* All other tests pass when everything is rebuilt from scratch.
+See {ref}`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](https://docs.pytest.org/en/latest/fixture.html#fixture)
+
+* 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 save to a directory named test_images by default
+
+ ```bash
+ $ pytest arviz/tests/base_tests/.py --save
+ ```
+
+* Optionally save plots to a user named directory. This is useful for comparing changes across branches
+
+ ```bash
+ $ pytest arviz/tests/base_tests/.py --save user_defined_directory
+ ```
+
+
+* Code coverage **cannot** decrease. Coverage can be checked with **pytest-cov** package:
+
+ ```bash
+ $ pip install pytest pytest-cov coverage
+ $ pytest --cov=arviz --cov-report=html arviz/tests/
+ ```
+
+* Your code has been formatted with [black](https://github.com/ambv/black) with a line length of 100 characters.
+
+ ```bash
+ $ pip install black
+ $ black arviz/ examples/ asv_benchmarks/
+ ```
+
+* Your code passes pylint
+
+ ```bash
+ $ pip install pylint
+ $ pylint arviz/
+ ```
+
+* No code style warnings, check with:
+
+ ```bash
+ $ ./scripts/lint.sh
+ ```
+
+(developing_in_docker)=
+# Developing in Docker
+
+We have provided a Dockerfile which helps for isolating build problems, and local development.
+Install [Docker](https://www.docker.com/) for your operating system, clone this repo. Docker will generate an environment with your local copy of `arviz` with all the packages in Dockerfile.
+
+## container.sh & container.ps1
+
+Predefined docker commands can be run with a `./scripts/container.sh` (on Linux and macOS)
+and with `./scripts/container.ps1`. The scripts enables developer easily to call predefined docker commands.
+User can use one or multiple flags.
+
+They are executed on the following order: clear-cache, build, test, docs, shell, notebook, lab
+
+ $ ./scripts/container.sh --clear-cache
+ $ ./scripts/container.sh --build
+
+ $ ./scripts/container.sh --test
+ $ ./scripts/container.sh --docs
+ $ ./scripts/container.sh --shell
+ $ ./scripts/container.sh --notebook
+ $ ./scripts/container.sh --lab
+
+
+ $ powershell.exe -File ./scripts/container.ps1 --clear-cache
+ $ powershell.exe -File ./scripts/container.ps1 --build
+
+ $ powershell.exe -File ./scripts/container.ps1 --test
+ $ powershell.exe -File ./scripts/container.ps1 --docs
+ $ powershell.exe -File ./scripts/container.ps1 --shell
+ $ powershell.exe -File ./scripts/container.ps1 --notebook
+ $ powershell.exe -File ./scripts/container.ps1 --lab
+
+## Testing in Docker
+Testing the code using docker consists of executing the same file 3 times (you may need root privileges to run it).
+First run `./scripts/container.sh --clear-cache`. Then run `./scripts/container.sh --build`. This starts a local docker image called `arviz`. Finally run the tests with `./scripts/container.sh --test`. This should be quite close to how the tests run on TravisCI.
+
+NOTE: If you run into errors due to `__pycache__` files (i.e. while testing in
+docker after testing locally or installing with pip after testing with
+docker), try running `./scripts/container.sh --clear-cache` before the errored
+command.
+
+## Using the Docker image interactively
+Once the Docker image is built with `./scripts/container.sh --build`, interactive containers can also be run. Therefore, code can be edited and executed using the docker container, but modifying directly the working directory of the host machine.
+
+To start a bash shell inside Docker, run:
+
+ $ docker run --mount type=bind,source="$(pwd)",target=/opt/arviz/ -it arviz bash
+
+and for Windows, use %CD% on cmd.exe and $pwd.Path on powershell.
+
+ $ docker run --mount type=bind,source=%CD%,target=/opt/arviz/ -it arviz bash
+
+Alternatively, to start a jupyter notebook, there are two steps, first run:
+
+ $ docker run --mount type=bind,source="$(pwd)",target=/opt/arviz/ --name jupyter-dock -it -d -p 8888:8888 arviz
+ $ docker exec jupyter-dock bash -c "pip install jupyter"
+ $ docker exec -it jupyter-dock bash -c "jupyter notebook --ip 0.0.0.0 --no-browser --allow-root"
+
+and the same on Windows
+
+ $ docker run --mount type=bind,source=%CD%,target=/opt/arviz/ --name jupyter-dock -it -d -p 8888:8888 arviz
+ $ docker exec jupyter-dock bash -c "pip install jupyter"
+ $ docker exec -it jupyter-dock bash -c "jupyter notebook --ip 0.0.0.0 --no-browser --allow-root"
+
+This will output something similar to `http://( or ):8888/?token=`, and can be accessed at `http://localhost:8888/?token=`.
+
+## Building documentation with Docker
+The documentation can be build with Docker by running `./scripts/container.sh
+--docs`. The docker image contains by default all dependencies needed
+for building the documentation. After having build the docs in the Docker
+container, they can be checked at `doc/build` and viewed in the browser from `doc/build/index.html`. To rebuild the docs re-run `./scripts/container.sh --docs` after making changes.
+
+# 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](https://github.com/scikit-learn/scikit-learn/blob/main/CONTRIBUTING.md)**
diff --git a/doc/source/contributing/developer_guide.md b/doc/source/contributing/developer_guide.md
new file mode 100644
index 0000000000..5c02112429
--- /dev/null
+++ b/doc/source/contributing/developer_guide.md
@@ -0,0 +1,129 @@
+(developer_guide)=
+
+# Developer Guide
+## Library architecture
+ArviZ is organized in modules (the folders in https://github.com/arviz-devs/arviz/tree/main/arviz).
+The main 3 modules are `data`, `plots` and `stats`,
+and then the `tests` folder is where tests for all these 3 modules are.
+
+The `static` is only used to store style and css files to get html output for `InferenceData` and
+`wrappers` is still experimental (not tested yet either) and interacts closely with
+both `data` and `stats` modules.
+
+In addition there are some files on the higher level directory: `utils.py`, `sel_utils.py`,
+`rcparams.py` and `labels.py`
+
+## plots
+ArviZ now supports multiple backends. If adding another backend please ensure you meeting the
+following design patterns.
+
+### Code Separation
+Each backend should be placed in a different module per the backend.
+See `arviz.plots.backends` for examples
+
+The code in the root level of `arviz.plots` should not contain
+any opinion on backend. The idea is that the root level plotting
+function performs math and construct keywords, and the backends
+code in `arviz.plots.backends` perform the backend specific
+keyword argument defaulting and plot behavior
+
+The convenience function `get_plotting_function` available in
+`arviz.plots.get_plotting_function` should be called to obtain
+the correct plotting function from the associated backend. If
+adding a new backend follow the pattern provided to programatically
+call the correct backend
+
+### Test Separation
+Tests for each backend should be split into their own module
+See `tests.test_plots_matplotlib` for an example
+
+### Gallery Examples
+Gallery examples are not required but encouraged. Examples are
+compiled into the arviz documentation website. The `examples` directory
+can be found in the root of the arviz git repository.
+
+
+## Documentation
+
+### Docstring style
+See the corresponding section in the {ref}`contributing guide `
+
+### Hyperlinks
+Complementary functions such as `compare` and `plot_compare` should reference
+each other in their docstrings using a hyperlink, not only by name. The same
+should happen with external functions whose usage is assumed to be known; a
+clear example of this situation are docstrings on `kwargs` passed to bokeh or
+matplotlib methods. This section covers how to reference functions from any
+part of the docstring or from the _See also_ section.
+
+#### Reference external libraries
+
+Sphinx is configured to ease referencing libraries ArviZ relies heavily on by
+using [intersphinx](https://docs.readthedocs.io/en/stable/guides/intersphinx.html).
+See guidance on the reference about how to link to objects from external
+libraries and the value of `intersphinx_mapping` in `conf.py` for the complete and up to
+date list of libraries that can be referenced. Note that the `:key:` before
+the reference must match the kind of object that is being referenced, it
+generally will not be `:ref:` nor `:doc:`. For
+example, for functions `:func:` has to be used and for class methods
+`:meth:`. The complete list of keys can be found [here](https://github.com/sphinx-doc/sphinx/blob/685e3fdb49c42b464e09ec955e1033e2a8729fff/sphinx/domains/python.py#L845-L881).
+
+The extension [sphobjinv](https://sphobjinv.readthedocs.io/en/latest/) can
+also be helpful in order to get the exact type and name of a reference. Below
+is an example on getting a reference from matplotlib docs:
+
+```
+$ sphobjinv suggest -t 90 -u https://matplotlib.org/objects.inv "axes.plot"
+
+Remote inventory found.
+
+:py:method:`matplotlib.axes.Axes.plot`
+:py:method:`matplotlib.axes.Axes.plot_date`
+:std:doc:`api/_as_gen/matplotlib.axes.Axes.plot`
+:std:doc:`api/_as_gen/matplotlib.axes.Axes.plot_date`
+```
+
+We can therefore link to matplotlib docs on `Axes.plot` from any docstring
+using:
+
+````{tabbed} rST
+```
+:meth:`mpl:matplotlib.axes.Axes.plot`
+```
+````
+````{tabbed} MyST (Markdown)
+```
+{meth}`mpl:matplotlib.axes.Axes.plot`
+```
+````
+
+
+The `intersphinx_mappings`
+defined for ArviZ can be seen in [`conf.py`](https://github.com/arviz-devs/arviz/blob/main/doc/conf.py).
+Moreover, the intersphinx key is optional. Thus, the pattern to get sphinx to generate links is:
+
+````{tabbed} rST
+```
+:type_id:`(intersphinx_key:)object_id`
+```
+````
+````{tabbed} MyST (Markdown)
+```
+{type_id}`(intersphinx_key:)object_id`
+```
+````
+
+with the part between brackets being optional. See the docstring on
+{meth}`~arviz.InferenceData.to_dataframe` and
+[its source](https://arviz-devs.github.io/arviz/_modules/arviz/data/inference_data.html#InferenceData.to_dataframe) for an example.
+
+#### Referencing ArviZ objects
+
+The same can be done to refer to ArviZ functions, in which case,
+``:func:`arviz.loo``` is enough, there is no need to use intersphinx.
+Moreover, using ``:func:`~arviz.loo``` will only show ``loo`` as link text
+due to the preceding ``~``.
+
+In addition, the _See also_ docstring section is also available. Sphinx will
+automatically add links to other ArviZ objects listed in the _See also_
+section.
diff --git a/doc/source/contributing/developer_guide.rst b/doc/source/contributing/developer_guide.rst
deleted file mode 100644
index da47af90cc..0000000000
--- a/doc/source/contributing/developer_guide.rst
+++ /dev/null
@@ -1,110 +0,0 @@
-.. developer_guide:
-
-
-===============
-Developer Guide
-===============
-
-
-Backends
-========
-ArviZ now supports multiple backends. If adding another backend please ensure you meeting the
-following design patterns.
-
-Code Separation
----------------
-Each backend should be placed in a different module per the backend.
-See ``arviz.plots.backends`` for examples
-
-The code in the root level of ``arviz.plots`` should not contain
-any opinion on backend. The idea is that the root level plotting
-function performs math and construct keywords, and the backends
-code in ``arviz.plots.backends`` perform the backend specific
-keyword argument defaulting and plot behavior
-
-The convenience function ``get_plotting_function`` available in
-``arviz.plots.get_plotting_function`` should be called to obtain
-the correct plotting function from the associated backend. If
-adding a new backend follow the pattern provided to programatically
-call the correct backend
-
-Test Separation
----------------
-Tests for each backend should be split into their own module
-See ``tests.test_plots_matplotlib`` for an example
-
-Gallery Examples
-----------------
-Gallery examples are not required but encouraged. Examples are
-compiled into the arviz documentation website. The ``examples`` directory
-can be found in the root of the arviz git repository.
-
-
-Documentation
-=============
-
-Docstring style
----------------
-See the corresponding section in the `contributing guide `_
-
-Hyperlinks
-----------
-Complementary functions such as ``compare`` and ``plot_compare`` should reference
-each other in their docstrings using a hyperlink, not only by name. The same
-should happen with external functions whose usage is assumed to be known; a
-clear example of this situation are docstrings on ``kwargs`` passed to bokeh or
-matplotlib methods. This section covers how to reference functions from any
-part of the docstring or from the `See also` section.
-
-Reference external libraries
-""""""""""""""""""""""""""""
-
-Sphinx is configured to ease referencing libraries ArviZ relies heavily on by
-using `intersphinx `_.
-See guidance on the reference about how to link to objects from external
-libraries and the value of ``intersphinx_mapping`` in ``conf.py`` for the complete and up to
-date list of libraries that can be referenced. Note that the ``:key:`` before
-the reference must match the kind of object that is being referenced, it
-generally will not be ``:ref:`` nor ``:doc:``. For
-example, for functions ``:func:`` has to be used and for class methods
-``:meth:``. The complete list of keys can be found `here `_.
-
-The extension `sphobjinv `_ can
-also be helpful in order to get the exact type and name of a reference. Below
-is an example on getting a reference from matplotlib docs::
-
- $ sphobjinv suggest -t 90 -u https://matplotlib.org/objects.inv "axes.plot"
-
- Remote inventory found.
-
- :py:method:`matplotlib.axes.Axes.plot`
- :py:method:`matplotlib.axes.Axes.plot_date`
- :std:doc:`api/_as_gen/matplotlib.axes.Axes.plot`
- :std:doc:`api/_as_gen/matplotlib.axes.Axes.plot_date`
-
-We can therefore link to matplotlib docs on ``Axes.plot`` from any docstring
-using::
-
- :meth:`mpl:matplotlib.axes.Axes.plot`
-
-The `intersphinx_mappings`
-defined for ArviZ can be seen in `conf.py `_.
-Moreover, the intersphinx key is optional. Thus, the pattern to get sphinx to generate links is::
-
- :type_id:`(intersphinx_key:)object_id`
-
-with the part between brackets being optional. See the docstring on
-:meth:`~arviz.InferenceData.to_dataframe` and
-`its source `_ for an example.
-
-Referencing ArviZ objects
-"""""""""""""""""""""""""
-
-The same can be done to refer to ArviZ functions, in which case,
-``:func:`arviz.loo``` is enough, there is no need to use ``intersphinx``.
-Moreover, using ``:func:`~arviz.loo``` will only show ``loo`` as link text
-due to the preceding ``~``.
-
-In addition, the `See also` docstring section is also available. Sphinx will
-automatically add links to other ArviZ objects listed in the `See also`
-section.
diff --git a/doc/source/contributing/index.md b/doc/source/contributing/index.md
index 84f28a3759..901551d122 100644
--- a/doc/source/contributing/index.md
+++ b/doc/source/contributing/index.md
@@ -1,9 +1,39 @@
-(contributing_docs)=
-# Contributing
+(contributing_guide)=
+# Contributing to ArviZ
+As a scientific, community-driven, open source 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.
+
+Even though contributing code or documentation by sending pull requests on
+the main ArviZ GitHub repository is the most common way of contributing and
+therefore also what this guide dedicates more resources, ArviZ welcomes
+any kind of contributions.
+As a clear proof, you can become a core contributor and participate in
+[ArviZ governance](https://github.com/arviz-devs/arviz/blob/main/GOVERNANCE.md)
+without having contributed code to ArviZ.
+All contributions to ArviZ, either on its codebase, its documentation
+or its community are valuable.
+
+Contact us on [Gitter](https://gitter.im/arviz-devs/community) if you want to
+contribute to the project but you are not sure where you can contribute.
+
+There are 4 main ways of contributing to the ArviZ _codebase_
+(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 (`arviz/examples`)
+* Submitting issues related to bugs or desired enhancements. Details at {doc}`issue_reports`
+
+Further information on how to contribute to ArviZ can be found at the specific pages:
```{toctree}
-:maxdepth: 3
+:maxdepth: 2
-contributing
+issue_reports
+contributing_prs
developer_guide
```
diff --git a/doc/source/contributing/issue_reports.md b/doc/source/contributing/issue_reports.md
new file mode 100644
index 0000000000..3590db1447
--- /dev/null
+++ b/doc/source/contributing/issue_reports.md
@@ -0,0 +1,38 @@
+# Issue reports
+
+We appreciate being notified of problems with the existing ArviZ code.
+We prefer that issues be filed the on
+[Github Issue Tracker](https://github.com/arviz-devs/arviz/issues),
+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.
+
+When writing an issue, make sure to include any supporting information,
+in particular the version of ArviZ that you are using and how did you install it.
+The issue tracker has several templates available to help in writing the issue
+and including useful supporting information.
+
+## Minimal reproducible example
+If your issue reports a bug or tires to show a specific behaviour,
+provide a way to reproduce the issue. Consider the advice on
+[stackoverflow](https://stackoverflow.com/help/minimal-reproducible-example)
+about writing a mininal reproducible code example.
+
+If even a minimal version of the code is still too long to comfortably share
+in the issue text, upload the code snippet as a
+[GitHub Gist](https://gist.github.com/) or a standalone Jupyter notebook.
+
+## Sharing error tracebacks
+If relevant, also include the complete error messages and tracebacks.
+To avoid cluttering the issue body, you can optionally use the `details`
+html tag in GitHub to create a simple dropdown, like so:
+
+````
+```
+Click to see full traceback
+long and barely comprehensible error traceback
+```
+
+````
diff --git a/doc/source/core_contributors.md b/doc/source/core_contributors.md
new file mode 100644
index 0000000000..0701d42045
--- /dev/null
+++ b/doc/source/core_contributors.md
@@ -0,0 +1,115 @@
+```{panels}
+:column: col-lg-3 col-md-4 col-sm-4 col-xs-6 p-2
+
+---
+:img-top: https://avatars.githubusercontent.com/u/23738400
+
+Oriol Abril-Pla
+
+[{fa}`style=fab,github`](https://github.com/oriolabril)
+[{fa}`style=fab,twitter`](https://twitter.com/OriolAbril)
+[{fa}`globe`](https://oriolabril.github.io/oriol_unraveled)
+
+---
+:img-top: https://avatars.githubusercontent.com/u/8028618
+
+Agustina Arroyuelo
+
+[{fa}`style=fab,github`](https://github.com/agustinaarroyuelo)
+[{fa}`style=fab,twitter`](https://twitter.com/AgustinaArroyu1)
+
+---
+:img-top: https://avatars.githubusercontent.com/u/30447180
+
+Alex Andorra
+
+[{fa}`style=fab,github`](https://github.com/AlexAndorra)
+[{fa}`style=fab,twitter`](https://twitter.com/alex_andorra)
+[{fa}`globe`](https://www.learnbayesstats.com/)
+
+---
+:img-top: https://avatars.githubusercontent.com/u/8673634
+
+Seth Axen
+
+[{fa}`style=fab,github`](https://github.com/sethaxen)
+[{fa}`style=fab,twitter`](https://twitter.com/sethaxen)
+[{fa}`globe`](https://sethaxen.com/)
+
+---
+:img-top: https://avatars.githubusercontent.com/u/2295568
+
+Colin Carroll
+
+[{fa}`style=fab,github`](https://github.com/ColCarroll)
+[{fa}`style=fab,twitter`](https://twitter.com/colindcarroll)
+[{fa}`globe`](https://colindcarroll.com/)
+
+---
+:img-top: https://avatars.githubusercontent.com/u/20489158
+
+Piyush Gautam
+
+[{fa}`style=fab,github`](https://github.com/percygautam)
+[{fa}`style=fab,twitter`](https://twitter.com/percygautam)
+
+---
+:img-top: https://avatars.githubusercontent.com/u/3274
+
+Robert P. Goldman
+
+[{fa}`style=fab,github`](https://github.com/rpgoldman)
+
+---
+:img-top: https://avatars.githubusercontent.com/u/13161958
+
+Ari Hartikainen
+
+[{fa}`style=fab,github`](https://github.com/ahartikainen)
+[{fa}`style=fab,twitter`](https://twitter.com/a_hartikainen)
+
+---
+:img-top: https://avatars.githubusercontent.com/u/7213793
+
+Ravin Kumar
+
+[{fa}`style=fab,github`](https://github.com/canyon289)
+[{fa}`style=fab,twitter`](https://twitter.com/canyon289)
+[{fa}`globe`](http://ravinkumar.com)
+
+---
+:img-top: https://avatars.githubusercontent.com/u/1338958
+
+Osvaldo Martin
+
+[{fa}`style=fab,github`](https://github.com/aloctavodia)
+[{fa}`style=fab,twitter`](https://twitter.com/aloctavodia)
+[{fa}`globe`](https://aloctavodia.github.io/)
+
+---
+:img-top: https://avatars.githubusercontent.com/u/5466612
+
+Mitzi Morris
+
+[{fa}`style=fab,github`](https://github.com/mitzimorris)
+[{fa}`style=fab,twitter`](https://twitter.com/searchbooster_)
+
+---
+:img-top: https://avatars.githubusercontent.com/u/4736342
+
+Du Phan
+
+[{fa}`style=fab,github`](https://github.com/fehiepsi)
+[{fa}`style=fab,twitter`](https://twitter.com/fehiepsi)
+[{fa}`globe`](http://fehiepsi.github.io/)
+
+---
+:img-top: https://avatars.githubusercontent.com/u/6705400
+
+Aki Vehtari
+
+[{fa}`style=fab,github`](https://github.com/avehtari)
+[{fa}`style=fab,twitter`](https://twitter.com/avehtari)
+[{fa}`globe`](https://users.aalto.fi/~ave/)
+
+```
diff --git a/doc/source/external_resources.md b/doc/source/external_resources.md
new file mode 100644
index 0000000000..7e8426f791
--- /dev/null
+++ b/doc/source/external_resources.md
@@ -0,0 +1,60 @@
+````{panels}
+:column: col-lg-4 col-md-4 col-sm-6 col-xs-12
+
+---
+:img-top: https://raw.githubusercontent.com/pymc-devs/pymc3/master/docs/logos/PyMC3.png
+:img-top-cls: pl-5 pr-5
+
+
+```{link-button} https://github.com/pymc-devs/pymc-examples
+:text: PyMC3 example notebooks
+:classes: btn-link stretched-link
+```
+
+Curated selection of PyMC3 guides and case studies.
++++
+Examples authored by PyMC3 developers and expert users.
+
+
+---
+:img-top: https://raw.githubusercontent.com/stan-dev/logos/master/logo.png
+:img-top-cls: pl-5 pr-5
+
+```{link-button} https://mc-stan.org/users/documentation/case-studies
+:text: Stan case studies
+:classes: btn-link stretched-link
+```
+
+The case studies on this page are intended to reflect best practices in Bayesian methodology and Stan programming.
++++
+Examples authored by Stan developers and expert users.
+
+---
+:img-top: _static/images/bambi.png
+
+
+```{link-button} https://github.com/bambinos/Bambi_resources
+:text: Bambi educational resources
+:classes: btn-link stretched-link
+```
+
+Bambi is a high-level Bayesian model-building interface written in Python,
+designed to make it extremely easy to fit mixed-effects models.
++++
+Tutorials and book translations maintained by the Bambi team
+
+---
+:img-top: https://oriolabril.github.io/oriol_unraveled/images/nb/labeled_arys.png
+
+```{link-button} https://oriolabril.github.io/oriol_unraveled/categories/#arviz
+:text: Oriol unraveled
+:classes: btn-link stretched-link
+```
+
+Blog mostly on statistics, diversity and open source. I also use the blog as a playground
+ground to test new pages for ArviZ docs.
++++
+Oriol Abril Pla is an ArviZ core contributor pursuing his PhD
+at Helsinki University
+
+````
diff --git a/doc/source/getting_started/Installation.rst b/doc/source/getting_started/Installation.rst
index 0c2c421ab0..953df1198a 100644
--- a/doc/source/getting_started/Installation.rst
+++ b/doc/source/getting_started/Installation.rst
@@ -9,7 +9,7 @@ dependencies to further enhance the library. This guide will cover both basic an
******
Stable
-******
+******
ArviZ can be installed either using pip or conda-forge.
@@ -25,7 +25,7 @@ Use the below pip command to install ArviZ with all of it's :ref:`Optional-depen
.. code:: bash
pip install arviz[all]
-
+
Using conda-forge
=================
@@ -37,7 +37,7 @@ Using conda-forge
***********
Development
-***********
+***********
If you want to install the latest development version of ArviZ, then you
may use
@@ -46,6 +46,7 @@ may use
pip install git+https://github.com/arviz-devs/arviz
+.. _arviz-dependencies:
************
Dependencies
@@ -71,7 +72,7 @@ The list of optional dependencies to further enhance ArviZ are.
- Numba
Necessary to speed up the code computation. The installation details can be found
- `here `_. Further details on enhanced functionality provided in ArviZ by Numba can be
+ `here `_. Further details on enhanced functionality provided in ArviZ by Numba can be
`found here `_.
- Bokeh
@@ -86,7 +87,7 @@ The list of optional dependencies to further enhance ArviZ are.
- Dask
Necessary to scale the packages and the surrounding ecosystem. The installation details can be found `at this link `_.
-
+
diff --git a/doc/source/getting_started/index.md b/doc/source/getting_started/index.md
index ae106f1384..e3678b6f73 100644
--- a/doc/source/getting_started/index.md
+++ b/doc/source/getting_started/index.md
@@ -3,6 +3,8 @@
# Getting Started
```{toctree}
+:maxdepth: 2
+
Installation
Introduction
XarrayforArviZ
diff --git a/doc/source/index.rst b/doc/source/index.rst
index 7c7074da27..c153842e0f 100644
--- a/doc/source/index.rst
+++ b/doc/source/index.rst
@@ -99,9 +99,9 @@ If you use ArviZ and want to **cite** it please use |JOSS|. Here is the citation
Example Gallery
user_guide/index
api/index
- usage
- contributing/index
- about
+ community
+ Contributing
+ about_us
.. raw:: html
diff --git a/doc/source/usage.rst b/doc/source/usage.rst
deleted file mode 100644
index ac5e07948d..0000000000
--- a/doc/source/usage.rst
+++ /dev/null
@@ -1,46 +0,0 @@
-.. usage:
-
-:ref: `api.rst`
-
-*****
-Usage
-*****
-
-There are a couple avenues for help on ArviZ usage
-
-
-Documentation
-==============
-ArviZ has multiple styles of documentation.
-We welcome `contributions `_
-
-
-QuickStart
-##########
-If new to the library the best place to start is the
-:ref:`quickstart `
-
-
-Example Gallery
-###############
-The gallery provides high level overviews of each of the plots. The code to generate the figures
-can be copied from your browser,
-or found in the `Github repository `_
-
-
-Method Documentation
-####################
-Each method is documented in the :ref:`the API page `. Although not complete at time of
-writing we are working on providing inline examples for each method.
-
-
-Additional Questions
-====================
-For questions not answered by the documentation we offer the following avenues.
-
-
-Github Issues
-#############
-A Github issue can be created for general purpose questions. Please use the
-`provided template `_
-with the label **question**.