This may be a personal thing but when I’ve made contributions to other OSS projects I generally care more about getting the change in than I am attached to my particular code / implementation. So I always look at it as a win-win when someone takes my contribution and runs with it - I can always go back and look at the changes to learn if I want.
Plus isn’t this a configurable setting? i.e. when I open a PR from my fork I can “allow edits from maintainers” <https://docs.github.com/en/pull-requests/how-tos/work-with-forks/allowing-changes-to-a-pull-request-branch-created-from-a-fork>, and you could argue I’m opting into this approach by checking that box. > On Oct 6, 2026, at 12:40 PM, Jarek Potiuk <[email protected]> wrote: > > 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] >
