Just to share my experience - I think I did it many times (more than
50) and never got any push-back. But of course that might be because
people are shy / afraid to oppose me (I have a reputation for being
difficult).
But when you think about it, there is no big **issue**:
* merging means that is no longer **author's code** - it becomes
"community code"
* maintainer's job is to make sure that the code is good and
maintainable (this approach makes it works)
* authorship remains - but also it's there is a co-author (this is
what is recorded in commit)
* if the committer does not agree with author, they can merge follow
up commit changing things anyway
So - putting aside some possible personal ("it's my own, my precious")
approach - I see no disadvantages of such an approach.
J.
On Tue, Oct 6, 2026 at 6:28 PM Ferruzzi, Dennis via dev
<[email protected]> wrote:
>
> I've definitely considered it, but have not yet done it. I think I'm
> concerned that the contributor may take it the wrong way rather than "I just
> fixed it while I was in there" and "it took just as long to fix it as it
> would have taken to explain it".
>
> - ferruzzi
> ________________________________
> From: Jarek Potiuk <[email protected]>
> Sent: Tuesday, October 6, 2026 1:17 AM
> To: [email protected] <[email protected]>
> Subject: [EXT] [DISCUSS] Merging "almost" ready PRs with maintainer-fixups
> from contributors
>
> CAUTION: This email originated from outside of the organization. Do not click
> links or open attachments unless you can confirm the sender and know the
> content is safe.
>
>
>
> AVERTISSEMENT: Ce courrier électronique provient d’un expéditeur externe. Ne
> cliquez sur aucun lien et n’ouvrez aucune pièce jointe si vous ne pouvez pas
> confirmer l’identité de l’expéditeur et si vous n’êtes pas certain que le
> contenu ne présente aucun risque.
>
>
>
> Hello everyone,
>
> In order to improve our "agentic AI" workflows, I have recently
> changed my approach for pull requests that are "almost ready" and need
> only small fixes, such as mechanical conflicts, typos, or minor
> comment updates. I would love to get your feedback on this pattern.
>
> Previously, when a PR had one or two minor issues, I would approve it,
> add inline comments specifying the necessary changes, and ask the
> author to fix them. Recently, I have often adopted this approach
> instead:
>
> - Make inline comments explaining the issue
> - Rebase and remove conflicts if needed
> - Apply the fixup myself (pushing directly to the contributor's branch).
> - Comment and resolve my own inline comments.
> - Approve and merge once CI checks pass.
>
> I only do this for small gaps, edge cases, mechanical fixes, or
> documentation updates that do not alter the substance of the PR. The
> PR remains primarily the author's work, with minor co-authored fixes.
>
> This pattern offers several benefits:
>
> - Efficiency: With agentic-assisted reviews, the AI already has the
> context and proposed fix, taking only seconds to apply and push.
> - Faster Merges: Eliminates additional review roundtrips and avoids
> new conflicts from interim merges.
> - Fewer Iterations: Prevents extra back-and-forth if a comment is
> misunderstood or incompletely fixed.
> - Keeps Educational Value: The author receives both an explanation
> of the issue and code for the solution.
> - PR Capacity: Frees up contributor PR slots sooner.
> - Throughput: Helps us process a higher volume of PRs more quickly.
>
> The main tradeoff is that the author learns by reading rather than
> doing, which could potentially lead to a more relaxed approach to
> minor details. However, if restricted strictly to minor, mechanical
> adjustments—while still using "Request Changes" for larger gaps—I
> believe the benefits outweigh the downsides.
>
> I would love to hear what others—especially contributors and fellow
> maintainers—think about this workflow.
>
> Best regards,
> Jarek
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
