“Minimum Versions” policy looks to me like something only maintainers would need to know when making decisions about changing one. Contributors may need to know what the current minimum version is, but they can get that from the “Dependencies” page. Contributors do not in general need to know how minimum versions are decided.

I think I'm largely OK with the top-level outline (contribute, setup, policies). I think whoever does this should just make an outline with the second level below that and then re-organize what we have (being careful to keep cross links). I actually don't feel this would be that hard as we already have a tonne of awesome material that folks have contributed over the last couple of years.

Process:

What I would suggest for relatively large re-organizations like this is that we should consider moving away from the direct review process. Unlike a feature in the code, which is usually sort of cut and dried, writing documentation always has a component of artistic license, and my experience with the process here indicates that it is gruelling to get big changes through the usual review process because many individuals always have their idea of how to re-organize and/or have many small suggestions. PRs stall out for weeks or months over these, and folks are not willing to merge over them.

A model I think may work better, is for at least two like-minded contributors to propose to the group, and ultimately the steering council or @tacaswell, that they be given license to re-organize a section. They would of course make a PR (or PRs) that can be publicly commented on etc. However, it would be understood that the two people would eventually merge the work, even if there are outstanding suggestions about exactly what has been done. Two people ensures some quality control and proof reading. I'd suggest the amount of work involved in suggestions and proof reading would make the two contributors co-authors on any commits.

I think if we had this as a model for re-orginzations such as proposed here, the job is not so monumental. For instance, @story645 if you and @melissawm (for example) wanted to co-author a re-org of the contributing/dev section, I would imagine you'd have support from the group. I guess a way to propose this would be to write an outline of the re-org (two levels or so deep), and propose a reasonable timeline, and then get buy in.

Anyway, that is just my suggestion for how to get larger documentation projects through - I'm sure there are other models.

copying my next phase proposal from #28557 (comment)

rough plan for more clean up/polishing that should roughly close out the tasks above:

• waiting on Add branch tracking to development workflow instructions #28575, [Doc]: helping new contributors with choosing issues to work on  #28476, and Doc: added triage section to new contributor docs #28347 for:
  • integrating "how to PR" into "dev workflow"
  • remove dependencies toctree
  • rewriting rebase section to be less theory
• waiting on Doc: doc docs reorg #28578 for cleaning up the doc docs:
  • make table of build options
  • put windows options in tabs
  • move misc topics into main sections, see [Doc]: add old sphinx tutorial to our devdocs #23903 for where to put things
• small rework on the triage docs:
  • Maybe spin out issue triage from PR triage and integrate adding saved replies to development guide, under triage #23109
  • maybe add something like the following flowchart based on lots of convos at scipy about best practice:

graph TD;
    A(is the issue) -->unresolvable-->C(explain why <br /> technically infeasible <br /> or not aligned with <br /> values/mission/scope/etc);
    A-->resolved--> B(explain why, <br /> link to docs, API, etc) ;
    A-->resolvable-->D(work w/ issue author <br /> on an implementable <br /> code/docs solution)
   A-->E(not sure)-->F(ask for more information) -->A;