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]
