[PR #14790/8d5a9660 backport][9.1.x] Doc: commit access follows demonstrated judgement, not a single clean PR

[patchback]

This is a backport of PR #14790 as merged into main (8d5a966).

In #14694, @breidenbach0 asked for commit access after their pull request landed. That was an entirely reasonable thing to do: CONTRIBUTING.rst has said since 2016 that

Anyone who has successfully seen through a pull request which did not require any extra work from the development team to merge will themselves gain commit access if they so wish (if we forget to ask please send a friendly reminder).

The contribution itself was good and welcome — the mismatch was in our document, not in the ask. @lovetheguitar pointed out that the wording invites exactly this, and suggested we say something closer to "we offer it once trust is built".

Why the old rule made sense. It was never really about the one pull request; that was a proxy. Back then, pushing something significant through in one shot meant a contributor had already developed a sense for the project. By the time someone cleared the bar they were effectively established, and offering the commit bit only made official what was already the case.

Why it stopped working. Two things shifted. pytest carries considerably more responsibility now, so merge rights weigh more than they did. And with capable agents, a pull request that merges without back and forth is much cheaper to produce than the sensibilities the rule was standing in for. The proxy and the thing it proxied have come apart.

What this PR does. It writes down what we actually go by: a developed sense for the project's scope, conventions and the cost of a change, shown across contributions, reviews and discussions — an invitation the team extends, not a bar a contributor clears on demand. It drops the "send a friendly reminder" line that directly invited the ask, and adds that not having been asked yet is not a verdict on anyone's work.

The section in full:

Commit access is an invitation the development team extends once a contributor has shown a developed sense for the project -- its scope, its conventions, and what a change costs the people who depend on it. We look for that across contributions, reviews and discussions rather than in any single pull request, so there is nothing to clear on demand; if we haven't reached out yet, that is not a verdict on your work -- sometimes no-one has thought to offer.

The invitation does not change how you contribute: everyone goes through the same pull-request-and-review process, and no-one merges their own pull requests unless already approved. It does mean you can take a fuller part in the development process, since you can merge other contributors' pull requests once you have reviewed them.

Revised after review. @Pierre-Sassoulas, @bluetech and @webknjaz all said the same two things, and both are now addressed. The document no longer narrates the old policy — the account of what changed and why lives in the commit message instead, so the section stays short, we keep the flexibility that comes with saying less, and CONTRIBUTING.rst does not accumulate a paper trail every time the policy moves. And it no longer discourages anyone from asking: @bluetech's point that sometimes no maintainer simply thinks to offer is what the reassurance now says, in place of the earlier "please don't feel you have to ask".

No changelog entry: contributor documentation, not user-facing.