Restructure documentation

[schroedk]

Restructure the documentation into the top-level:

• getting started:

  • Installation: basics, extras, links to tutorials, links to method explanation

• tutorials:

  • detecting corrupted labels: synthetic influence, CNN (malaria example?)
  • outlier analysis: wine
  • assigning value to data provider:
  • data pruning:
  • data selection:

• how-to guides:

  • scaling computation
  • how to speed up computation with parallelization
  • how to speed up computation with caching
  • basic setup of valuation objects
  • basic setup of influence objects
  • choosing and configure samplers
  • choosing sample sizes and stopping criteria
  • advanced configuration of influence computation
  • how to ensure reproducibility

• methods:

  • valuation
  • influences

• api:

  • user api
  • development

Take inspiration from

• https://nick.groenen.me/posts/the-4-types-of-technical-documentation/
• https://diataxis.fr/
• https://estimagic.org/en/latest/index.html

Convention:

• do not add math formulas to docstrings, but reference the documentation, explain the implication of parameter choices in docstring
• keep the docstrings as lean as possible and reference the documentation whenever possible
• tutorials should be motivated by tasks

Wish list:

• short summary to check if user is on the correct documentation page
• list of related topics at the beginning of every documentation page

[AnesBenmerzoug]

As another suggestion, we should write the how-to guides and tutorials as notebooks and execute them, when possible, in CI with caching (with jupyter-cache?) in order to make sure they always run successfully. We should also consider putting directly in the corresponding subdirectory of the docs directory to avoid having to copy them every time.

[mdbenito]

Given the current lack of human-power I am moving this to v0.11.0. I will try to implement some of these ideas in #653