I do this from time to time (probably not 50+ times, though...), but mostly with contributors only. If I were that contributor, I'd be perfectly fine with someone making a small fix to my PR and merging it. At the end of the day, we're here to get the problem solved.
Best, Wei On 2026/10/06 16:52:08 Jarek Potiuk wrote: > > 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. > > Yes. It is. For example all astronomer people contributing from > astronomer repo have it disabled :D > > On Tue, Oct 6, 2026 at 6:47 PM Julian LaNeve via dev > <[email protected]> wrote: > > > > 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] > > > > > > > --------------------------------------------------------------------- > 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]
