Zero objections to this. I think most contributors would prefer that these minor suggestions be applied were for them as they would no longer have to revisit the PR and apply the suggestions themselves.
On Tue, 6 Oct 2026 at 19:13, Blain David <[email protected]> wrote: > I'm too in favor of this idea as this will speed up PR's being merged and > indeed reduce unnecessary roundtrips in the review process which is a waste > of time for both the author and reviewer. > > I also like the checkbox idea, which could be enabled by default, that way > the author still decides if he/she agrees to it or not. > > > ________________________________ > From: Wei Lee <[email protected]> > Sent: Tuesday, October 06, 2026 19:51 > To: [email protected] <[email protected]> > Subject: Re: [DISCUSS] Merging "almost" ready PRs with maintainer-fixups > from contributors > > EXTERNAL MAIL: Indien je de afzender van deze e-mail niet kent en deze > niet vertrouwt, klik niet op een link of open geen bijlages. Bij twijfel, > stuur deze e-mail als bijlage naar [email protected]<mailto: > [email protected]>. > > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.github.com%2Fen%2Fpull-requests%2Fhow-tos%2Fwork-with-forks%2Fallowing-changes-to-a-pull-request-branch-created-from-a-fork&data=05%7C02%7Cdavid.blain%40infrabel.be%7C14b598d5e56b4919556908df23d2ac88%7Cb82bc314ab8e4d6fb18946f02e1f27f2%7C0%7C0%7C639269059899612089%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=xR5pNT9fbnI9qKuluUpYZoiJyHb4aXm%2FQ2AQUodexm0%3D&reserved=0 > < > 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.github.com%2Fen%2Fpull-requests%2Fhow-tos%2Fwork-with-forks%2Fallowing-changes-to-a-pull-request-branch-created-from-a-fork&data=05%7C02%7Cdavid.blain%40infrabel.be%7C14b598d5e56b4919556908df23d2ac88%7Cb82bc314ab8e4d6fb18946f02e1f27f2%7C0%7C0%7C639269059899628590%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=suVhvBioJxucj4CbCeuplEkhSLwSqOgK7eiFdbwtKmU%3D&reserved=0 > < > 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] > > > General (Internal Property) >
