Write ArviZ docs guide

doc/source/conf.py

@@ -320,4 +320,17 @@ def ipython_directive_transform(source):
     "zarr": ("https://zarr.readthedocs.io/en/stable/", None),
     "numpy": ("https://numpy.org/doc/stable/", None),
     "dask": ("https://docs.dask.org/en/latest/", None),
+    "sphinx-primer": ("https://sphinx-primer.readthedocs.io/en/latest/", None),
+    "sphinx": ("https://www.sphinx-doc.org/en/master/", None),
+    "diataxis": ("https://diataxis.fr/", None),
 }
+
+def setup(app):
+    # this needs to be added so we can reference confval targets
+    # in the doc contributing pages and explain what values we use and why
+    app.add_object_type(
+        'confval',
+        'confval',
+        objname='configuration value',
+        indextemplate='pair: %s; configuration value'
+    )

doc/source/contributing/architecture.md

@@ -0,0 +1,15 @@
+# Library architecture
+ArviZ is organized in modules (the folders in [arviz directory](https://github.com/arviz-devs/arviz/tree/main/arviz)).
+The main 3 modules are `data`, `plots` and `stats`.
+Then we have 3 more folders. The [tests](https://github.com/arviz-devs/arviz/tree/main/arviz/tests)
+folder contains tests for all these 3 modules.
+
+The [static](https://github.com/arviz-devs/arviz/tree/main/arviz/static)
+folder is only used to store style and CSS files to get HTML output for `InferenceData`.
+Finally we have the [wrappers](https://github.com/arviz-devs/arviz/tree/main/arviz/wrappers)
+folder that contains experimental (not tested yet either) features
+and interacts closely with both [data](https://github.com/arviz-devs/arviz/tree/main/arviz/data)
+and [stats](https://github.com/arviz-devs/arviz/tree/main/arviz/stats) modules.
+
+In addition, there are some files on the higher level directory: `utils.py`, `sel_utils.py`,
+`rcparams.py` and `labels.py`.

doc/source/contributing/content_structure.md

@@ -0,0 +1,89 @@
+(content_structure)=
+# Documentation content structure
+
+ArviZ documentation has the {doc}`diataxis:index` as a North Star.
+This page assumes basic familiarity with Diátaxis.
+
+The ArviZ website is divided into three content blocks:
+
+* ArviZ user documentation
+* ArviZ contributor documentation
+* ArviZ Project website
+
+## ArviZ user documentation
+It is the block formed by the navbar sections
+`Getting Started`, `Example Gallery`, `User Guide` and `API Reference`.
+
+It's audience are ArviZ users and it uses Diátaxis to achieve its goal of
+teaching how to use ArviZ.
+
+Getting Started
+: The Getting Started section should contain mostly tutorials, however, some
+  how-to content or overview explanations are also allowed and even encouraged
+
+Example Gallery
+: The Example Gallery is a visual reference section that should contain
+  **no description** of the functions used. It should instead link to the
+  API Reference section.
+
+  Its goal is to serve as visual index for users who know how their desired plot
+  looks like but not the name of the ArviZ function that generates it
+
+User Guide
+: The User Guide is targeted to people who already have basic ArviZ knowledge
+  and should mostly contain how-to guides.
+  It can also contain in-depth explanations and some non-python objects reference
+  content.
+
+API Reference
+: It should index and describe all ArviZ objects that are part of the public API,
+  that is, are exposed to ArviZ users. It should be generated from a list of
+  public objects only via sphinx extensions, taking the actual content from
+  the docstrings in each ArviZ object.
+
+## ArviZ contributor documentation
+It is all inside the `Contributing` navbar section.
+
+It's audience are any and all ArviZ contributors, from new contributors to members
+of the core team.
+It follows Diátaxis quite closely by using multiple captioned toctrees.
+
+Contribution types overview
+: Diátaxis explanation content. Contributing to ArviZ can be loosely undestood
+  as a single practical craft, but it is more of multiple practical crafts
+  coming together.
+
+  This section aims to provide high level overviews explaining different
+  contribution types, what skills are needed for them, why are they important
+  and guide the reader to their next steps in one of the following sections.
+
+Tutorials
+: Diátaxis tutorial content. Tutorials with clearly defined and small scope,
+  guiding new contributors in a single "atomic" contribution or even step
+  in the contribution process.
+
+How-to guides
+: Diátaxis how-to content. Guides that outline the steps for common processes
+  in the contributing workflow. Documenting this ensures it is available
+  for newcomers but also that all contributors use the same processes
+  which can reduce misunderstanding and frictions.
+
+Reference
+: Diátaxis reference content.
+
+In depth explanations
+: Diátaxis explanation content.
+
+## ArviZ Project website
+It is the block formed by the navbar sections
+`Community`, `About Us` and by the homepage.
+
+It's audience is anyone interested in the ArviZ project.
+This can well be users or contributors but it could also be someone
+who is neither. It has also no relation to any practical craft
+and does not follow Diátaxis at all.
+
+It should contain all the information related to the ArviZ community,
+meeting places (online of physical), shared resources, related
+projects and communities; and to the project itself, its members,
+its roadmap, its procedures...

doc/source/contributing/contributing_prs.md

@@ -36,22 +36,18 @@ If the issue is assigned then precedence goes to the assignee. However, if there
 
 (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. the details of this process are listed on
-{ref}`pr_checklist`. For a detailed
-description of the recommended development process, see {ref}`developer_guide`.
 
-### Code Formatting
+## 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)=
+# Docstring formatting and type hints
 
-### 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
@@ -67,182 +63,10 @@ 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
+## Documentation for user facing methods
 If changes are made to a method documented in the {ref}`ArviZ API Guide <api>`
 please consider adding inline documentation examples.
 You can refer to {func}`az.plot_posterior <arviz.plot_posterior>` for a good example.
 
-## Tests
+### 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.
-
-   ::::{tab-set}
-
-   :::{tab-item} SSH
-   :sync: ssh
-
-   ```
-   $ git clone git@github.com:<your GitHub handle>/arviz.git
-   ```
-   :::
-
-   :::{tab-item} HTTPS
-   :sync: https
-
-   ```
-   $ git clone https://github.com/<your GitHub handle>/arviz.git
-   ```
-   :::
-
-   ::::
-
-3. Navigate to your arviz directory and add the base repository as a remote:
-
-   ::::{tab-set}
-
-   :::{tab-item} SSH
-   :sync: ssh
-
-   ```
-   $ cd arviz
-   $ git remote add upstream git@github.com:arviz-devs/arviz.git
-   ```
-   :::
-
-   :::{tab-item} HTTPS
-   :sync: https
-
-   ```
-   $ cd arviz
-   $ git remote add upstream https://github.com/arviz-devs/arviz
-   ```
-   :::
-
-   ::::
-
-4. Create a ``feature`` branch to hold your development changes:
-
-   ```bash
-   $ git checkout -b my-feature
-   ```
-
-   ```{warning}
-   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](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, for developing the project in [Docker](https://docs.docker.com/), there is a script to setup the Docker environment for development. See {ref}`developing_in_docker`.
-
-6. Develop the feature on your feature branch. Add your changes using git commands, ``git add`` and then ``git commit``, like:
-
-   ```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
-   ```
-
-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.
-
-(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 a 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/](https://github.com/arviz-devs/arviz/tree/main/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 be saved to a directory named `test_images` by default.
-
-  ```bash
-  $ 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.
-
-  ```bash
-  $ 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:
-
-  ```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
-  ```
-
-## 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)**.