<[email protected]> wrote: > That probably wasn’t very clear. > > “This” = allowing commits from maintainers on PRs opened from the > astronomer/airflow fork, and the org policy is the on Astronomer GH org, > not in the Airflow GH org. >
Yep it's an org setting. And this is fine - it is in control of the person or organisations to enable/disable it - and it's perfectly fine for Astronomer or other orgs to disable this for their PRs - and in this case what might work instead is PR to the original PR :) > > On 7 Oct 2026, at 09: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] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
