Doc: commit access follows demonstrated judgement, not a single clean PR - #14790
Open
RonnyPfannschmidt wants to merge 1 commit into
Open
Doc: commit access follows demonstrated judgement, not a single clean PR#14790RonnyPfannschmidt wants to merge 1 commit into
RonnyPfannschmidt wants to merge 1 commit into
Conversation
Since 4c62cd4 (2016) the "Joining the Development Team" section has promised commit access to anyone who saw a pull request through that did not require extra work from the team, and invited contributors to remind us if we forgot to ask. That rule was sound when it was written. It was never really about the single pull request -- it was a proxy. Pushing something significant through in one shot meant a contributor had already developed a sense for the project, so by the time they cleared the bar they were effectively established, and handing them the commit bit only made official what was already true. The proxy no longer holds. The project carries considerably more responsibility than it did, so merge rights weigh more; and with capable agents, producing a pull request that merges without back and forth no longer demonstrates the sensibilities the rule was standing in for. Say 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 -- and an invitation we extend rather than a bar contributors clear on demand. The "send a friendly reminder" line goes with it, since it directly invited the ask, replaced by a note that not having been asked yet is not a verdict on anyone's work. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
RonnyPfannschmidt
added
the
skip news
Pierre-Sassoulas
approved these changes
Jul 28, 2026
Comment on lines
+490
to
+492
| Commit access does not change your contribution workflow: everyone goes | ||
| through the same pull-request-and-review process and no-one merges their own | ||
| pull requests unless already approved. It does however mean you can |
Comment on lines
+475
to
+481
| This section used to promise commit access to anyone who saw a pull request | ||
| through without the team having to do extra work. That bar was a good proxy | ||
| for the real thing back then: getting something non-trivial merged in one go | ||
| meant you had already built that sense. It no longer works as a proxy, both | ||
| because pytest carries far more responsibility today and because a pull | ||
| request that looks clean is now much cheaper to produce than the judgement | ||
| behind it. |
Member
There was a problem hiding this comment.
I'm not sure if we have to explain the past and the reason for the change here, maybe the PR description is the proper place. (but this can ship anyway)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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
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 keeps the history visible rather than pretending the old text was never our policy, 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.
No changelog entry: contributor documentation, not user-facing.