> 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]
