I think it's a very good idea, what we usually do (at our org) is that for small and minor changes, the reviewer adds suggestions, and the PR owner can accept if he agrees, this also solves the org policy issue IMO, maybe a good start is to encourage reviewers to leave suggestions for small changes rather than comments.
It is limited to small changes, but from my point of view, an "almost done" pr only needs minor fixups. In case the PR owner does not reply and the PR is stale this might not work, yet I think users with read access should be able to accept those suggestions as well Any thoughts about this proposal? On Wed, Oct 7, 2026, 11:59 Ash Berlin-Taylor <[email protected]> wrote: > Org policy prevents us from changing this I think. Or at least I have > never been able to find a setting that changes this :( > > > On 6 Oct 2026, at 17:52, Jarek Potiuk <[email protected]> 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] > >
