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.
> 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]
