DOC: add 2 review policy for large doc PRs - #32113

We do not need additional policy for this.

We do not need additional policy for this.

Why not? Going down the line on the reasoning behind two reviews:

• consistent project direction - large documentation changes can shape the direction of the docs, which is part of the project
• prevent accidental mistakes - more room for mistakes when the PR is large
• change is not fundamental - large doc changes can introduce fundamental changes to the docs
• can easily be reverted at any time in the future - large changes, especially when there are large moves or additions - are harder to revert, especially if those docs have been changed subsequently

We require 2 reviews on code that's much lower impact.

I would side with @story645 here. This is not a new policy. It's a corrolary in the spirit of our policy. We want to have reasonable agreement and thorough thoughts for large-scale doc restructuring. That does not happen often which is why we had generally declared doc changes as a one-pair-of-eyes case. I'm not sure whether we need to spell everything out explicitly, but I would say the new wording is more precise.

I'm personally of the opinion that 2-review is already burdensome, and that we would benefit from a process of single-maintainer code review on anything that's not hard to change (ie, everything except public API and major architecture). Leaning more towards a merge-and-iterate philosophy. Docs would definitely fall under that.

But in terms of codifying standing policy, I'm fine with this PR.

ie, everything except public API and major architecture

I think very large doc changes are equally a pain to undo; like roughly equivalent to major architecture changes in how much of the docs it impacts and how much work it takes to unwind/clean up.

But I also agree w/ you in terms of loosening the review requirements on simpler code PRs where the CI should be a good enough check (stuff like bugfixes). Basically I think there should be parity in how code and docs are treated/evaluated since they have about equivalent maintainance burden.

I agree this is being more explicit about what was already implicit.