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]
