Doc: commit access follows demonstrated judgement, not a single clean PR - #14790
Conversation
RonnyPfannschmidt
added
the
skip news
| 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 |
| 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. |
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)
|
I agree with the change, unfortunately the Turing test is no longer sufficient. I agree with @Pierre-Sassoulas that we don't need to explain the previous policy, it's not like we had people pounding at our doors that we need to explain why we changed the locks. I also think the new text is a bit too long, if it's shorter it gives us more flexibility. Particularly I don't think we need to discourage people from asking, sometimes it's just that no core maintainer thinks to offer. |
webknjaz
added
the
backport 9.1.x
webknjaz
left a comment
webknjaz
left a comment
There was a problem hiding this comment.
So sad that this now has to go in. I agree with what Pierre and Ran said wrt this being too long and the doc not necessarily needing to discourage the ask. We probably shouldn't have the history right in this doc — git commits aren't going anywhere + this will probably poison people agents' contexts more than needed. The commit message would be enough. Maybe, a wider ecosystem could benefit from a shared tribal knowledge doc of “here's the expectations” instead of maintaining a “here's our fork of the tribal knowledge adaptation 2026”), perhaps a new page on https://opensource.guide (it sorta started along those lines).
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. The section itself stays short and says only what we go by; the account of what changed and why lives here rather than in the document, so the policy can shift again without a paper trail accumulating in CONTRIBUTING.rst. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
8310c5b to
81c3a74
Compare
Backport to 9.1.x: 💚 backport PR created✅ Backport PR branch: Backported as #14836 🤖 @patchback |
…-an-invitation Doc: commit access follows demonstrated judgement, not a single clean PR (cherry picked from commit 8d5a966)
…d5a9660856b9626b93d1bfda200cd0aeb3a0403/pr-14790 [PR #14790/8d5a9660 backport][9.1.x] Doc: commit access follows demonstrated judgement, not a single clean PR
5 participants
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 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:
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.