Extend contributing docs

[OriolAbril]

I think it would be great to modify https://arviz-devs.github.io/arviz/contributing/index.html (it's source is markdown file at https://github.com/arviz-devs/arviz/blob/main/doc/source/contributing/index.md) to list more possible contributions.

The contributing section is currently composed of 4 files:

• index
• issue reports
• contributing_prs
• developer guide (doesn't concern this issue)

The index page contains the toctree and an overview about contributing to ArviZ, then we have the issue reports and the contributing prs files that give detailed guidance on different types of contributions. We should add more files about other types of contributions and then review the overview on the index file to make sure it's still relevant and doesn't focus too much on code PRs only. Also, it would be great to add a link to a blogpost or video testimonial by current contributors about their experience starting to contribute (cc @utkarsh-maheshwari who already has a post about that and aims to extend it). Sections/files to be added in my opinion are:

Issue triaging

I think it would be great to have a short file (like issue reports one more or less) explaining (or providing references to documentation explaining) 1) how to subscribe to arviz issues so they get notified of updates or new issues as well as how to unsubscribe manually from issues 2) explain how occasional contributors can help with issues even without triaging permissions 3) (can't be done yet) link to governance/contributing section about how to join ArviZ's private communication channels (and also get triage permissions on github?) cc @canyon289

Regarding point 2, some ideas that come to mind are:

• Make sure the issue contains a minimal working example if relevant. Sometimes, the issue doesn't contain such example but it is still clear about the problem and therefore, an example can be generated by someone other than the issue author. This will help whoever works on the fix by not requiring them to first reproduce the issue and then work on the fix as well as providing a test case.
• Make sure the issue is clear and has references if needed. Sometimes an issue will not be completely clear, so issue triagers can comment asking clarifications or adding extra references so the issue is clear enough for someone else to start working on it without needing to first clarify the issue. examples: Ensure dimension order can be anything #1693 (whole discussion), Posterior plot errors with boolean array #1694 (comment),
• Suggest fixes or workarounds. In some cases even, show that the issue has already been fixed on the development version but the fix is not yet released. examples: az.summary ignores the parameter coords #1732 (fixed in main but not on release), Using Arviz with Pymc3 and Tkinter #1692
• (requires triage permissions) label issues

It could also be useful to link to https://ropensci.org/tags/labelathon/ or some of the references in there to show the importance of this task.

Reviewing PRs

Similar to above, it should have instructions to subscribe to PRs to ArviZ repo, links to the contributing PRs file (but only to the checklist related sections) so reviewers are aware of what style and requirements PRs need to fulfill, links to a couple reference docs about how to give feedback. anyone has some ideas on that? it is not easy to review, give constructive and useful feedback and require changes if needed without being dismissive, making sure contributors now their effort and time is values...

Proofreading?

This could be a different section or contained within reviewing PRs. It would basically be reviewing PRs, but only to proofread changes in the documentation (that is changes to guides or docstrings). Not sure how to organize it, but we could for example have an open issue so proofreaders can manually subscribe to that issue only and whenever a PR needs proofreading, comment on the issue with the pr number to notify proofreaders.

other ideas?

Maybe documentation related contributions should have a different section to contributing_prs? Or one focused on doc design and content organization. Do we want some help with community management? twitter, discourse forums where arviz is relevant...

[OriolAbril]

one example of a blogpost testimonial from a recent sklearn sprint with data umbrella: https://sebastiandres.github.io/blog/sprint-data-umbrella-eng/