On Wed, Oct 7, 2026, 11:19 Natanel <[email protected]> wrote: > 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. >
Oh absolutely :). I think this is the 'gradation': comment/ online comment (blocking unless resolved currently) / inline comment with suggestion / direct fixup. And we should IMHO choose whatever is appropriate depending on 'scope' of fix and urgency of the PR - for example I am.much more info fixups just before preparing provider's release. > 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] > > > > >
