I'm up for forbiding conventional commits, but could you please open a new discussion thread for that? While being related, it will be hard to follow this specifically in this thread.
Shahar On Tue, Jun 16, 2026 at 4:07 PM Ash Berlin-Taylor <[email protected]> wrote: > Related to this whole discussion: > > I would like us to also enforce the Commit/PR message guidelines that we > already document - http://chris.beams.io/git-commit#imperative > > In particular, rule 5: > > > 5. Use the imperative mood in the subject line > > Imperative mood just means “spoken or written as if giving a command or > instruction”. > > This means that any PR that uses “conventional commits” (“fix:”, “feat:”, > “chore:” etc) and 99.9% of PRs without any commit bodies should not be > merged. > > -ash > > > On 15 Jun 2026, at 22:28, Sameer Mesiah <[email protected]> wrote: > > > > Hi Kaxil, > > > > I don't want to stretch this thread unnecessarily but I was curious if > you > > think that box really helps. From what I have experienced, it is rather > > obvious when a PR is entirely AI-generated. Again, different agentic > > systems have varying levels of efficacy but I am guessing most of the > > vanilla agents the unvetted contributors use hallucinate in very > > predictable ways (for example, changing unrelated files, adding a series > of > > dashes between each test etc). To a maintainer, simply glancing at the > diff > > should be enough for them to immediately tell. Not necessarily against > that > > checkbox being there but I think it is not needed to identify AI slop. > > > > On Mon, 15 Jun 2026 at 20:19, Kaxil Naik <[email protected]> wrote: > > > >> @Shahar Epstein <[email protected]> : I think both of us agree on the > need > >> for PR authors to add "the why and the what-to-watch-for/gotcha" -- so > I am > >> good with that. And looks like everyone on this thread has unanimously > >> agreed with that. > >> > >> My main disagreement was about whether making the checkbox to disclose > the > >> AI tool in use mandatory is the right way to determine if something is > AI > >> slop. > >> > >> We should still talk in 1:1 call though :) > >> > >> > >> On Mon, 15 Jun 2026 at 08:22, Jarek Potiuk <[email protected]> wrote: > >> > >>> Thank you, Yeongook. It's rare to see appreciation for relentless > >>> background improvements that others take for granted. They often don't > >> see > >>> how much time these improvements save them or how much better things > are > >>> for them even if they do not realise it. This is especially true when > >> there > >>> is a constant request for feedback and improvement—and immediate > reaction > >>> to constructive feedback other than "stop doing it, I do not like it," > >>> Furthermore, feedback is always and quickly addressed, comments are > >>> welcome, and I constantly show that I listen to everyone and respond to > >>> their input. > >>> > >>> That one message in the thread made my heart jump. It shows me that the > >>> direction I am taking is appreciated, seen and welcome by some, even if > >>> strong opposing voices—which sometimes verge on anger and > >>> aggression—suppress those quieter ones. > >>> > >>> Other than that part - I also 100% agree with what you wrote. AI just > >>> exposed the need for the much more focus on "why and what" rather than > >>> "how." I think we should all - collectively iterate and improve that > part > >>> of our "maintainership" rather than thinking one hidden comment will > >> solve > >>> it - when we do not work on the whole process and don't put > expectations > >> on > >>> ourselves - to be part of that process—instead of blaming others for > how > >>> "badly" their behaviour compares to what "I" would like to do. > >>> > >>> I think part of being in the community also involves sacrificing part > of > >>> what "I" want to do, as. a trade-off for much more positive > collaborative > >>> effects of "us" - even if it's not the perfect approach for "me". > >>> > >>> J. > >>> > >>> > >>> > >>> > >>> On Mon, Jun 15, 2026 at 2:59 AM Yeonguk Choo <[email protected]> > >>> wrote: > >>> > >>>> Hi, everyone, > >>>> I wanted to share a few thoughts after reading this thread. > >>>> > >>>> ### TL;DR: > >>>> I don't think the core issue is AI itself. > >>>> The challenge is preserving responsibility, context, and meaningful > >> human > >>>> participation. > >>>> Rather than detecting, requiring, or prohibiting AI, we should ensure > >>>> contributors understand their changes, can explain their reasoning, > and > >>>> take responsibility for the outcome — and reinforce that through a > >>> clearer > >>>> PR template and contributor guidance. > >>>> > >>>> ### What we're actually trying to solve > >>>> > >>>> The thread seems to have converged on a few symptoms: > >>>> > >>>> * PR volume is up but meaningful human participation is down > >>>> * When we ask why a change was made, we sometimes get the LLM's answer > >>>> rather than the contributor's > >>>> * Context is disappearing — it's harder to tell what problem a change > >>>> solves and what alternatives were weighed > >>>> > >>>> So the question isn't "Should we allow AI?" but "How do we keep a > >>>> responsible community in the age of AI?" > >>>> > >>>> I strongly relate to Ash's concern here. Banning AI won't solve this — > >>> and > >>>> AI alone won't either. > >>>> > >>>> ### Why context matters more now > >>>> > >>>> I've spent years helping grow the Airflow contributor community in > >> Korea > >>>> as a volunteer, simply because I love this project and its culture. > >>>> > >>>> One pattern I keep seeing: > >>>> * some contributors are careful and engaged with how the feature is > >>>> actually used; > >>>> * others open many PRs quickly with only shallow understanding of the > >>> area > >>>> they're changing > >>>> * and AI makes that second pattern far easier than before. > >>>> > >>>> Before AI, writing the code was itself a barrier to entry. > >>>> Now generating code and opening a PR is easy, so usage experience and > >>>> contextual understanding have become the scarce, valuable parts. > >>>> > >>>> Nobody needs to be a long-term operator. But a contributor should > >>>> understand the workflow they're changing — ideally through real use or > >>>> close contact with people who use it — and grasp, at least roughly, > the > >>>> problems the project is solving and why it evolved as it did. > >>>> > >>>> When code is written without real usage behind it, it can look correct > >> on > >>>> the page yet quietly diverge from how the system actually behaves. > >>>> > >>>> For example, on the UI side, lack of hands-on usage often leads to > >>>> over-engineered changes that miss the actual intent of the feature, or > >> to > >>>> visual regressions that were never validated in the browser — > resulting > >>> in > >>>> repeated cycles of screenshot requests or reverting unintended > changes. > >>>> > >>>> Solving an issue and owning the long-term impact of a change are not > >> the > >>>> same thing, and ownership is hard to sustain for a system you've never > >>> used. > >>>> > >>>> What I find most disappointing is the disappearance of genuine > >>> discussion. > >>>> > >>>> Incorrect reviews happen — mine, Copilot's, Claude's, Codex's, > >> anyone's — > >>>> that's fine. > >>>> What worries me is when reviews are accepted without critical > >> evaluation, > >>>> or when "Why this way? How do you reproduce it? What alternatives did > >> you > >>>> consider?" are effectively answered by an agent rather than the > >>> contributor > >>>> — or, all too often, go unanswered altogether. At that point it stops > >>>> feeling like a conversation between people. > >>>> > >>>> In some cases, even when issues are opened to discuss a change, the > >>>> discussion does not really happen in that space and instead quickly > >> moves > >>>> into implementation via pull requests. This further reduces the > >>> opportunity > >>>> for shared understanding and design-level discussion before code > >> changes > >>>> are introduced. > >>>> > >>>> ### A concrete, AI-neutral proposal > >>>> > >>>> Require the information we actually need in the PR template: > >>>> > >>>> - Why is this change necessary? What problem does it solve? > >>>> - How can it be reproduced? > >>>> - What alternatives were considered, and why this approach? > >>>> > >>>> and also add a short note to the template — and importantly, as a > >> VISIBLE > >>>> footer, not an HTML comment. > >>>> > >>>> Template instructions written as <!-- comments --> don't render in the > >> PR > >>>> and are routinely skipped. The whole point is that contributors and > >>>> reviewers actually see this: > >>>> > >>>>> "Airflow is a community-driven project. Maintainers may ask not only > >>>> about the implementation of a change, but about its motivation, > >> context, > >>>> and design decisions. Before entering review, please make sure you > >>>> understand your change well enough to explain why it was made and why > >>> this > >>>> approach was chosen." > >>>> > >>>> **And one consistent rule: ** > >>>> if the template isn't filled out, reviewers request completion before > >>>> starting the review — **no review until the minimum context is > >>> provided.** > >>>> > >>>> This gives every contribution the same baseline of context, regardless > >> of > >>>> who wrote it or whether AI was involved. > >>>> > >>>> If chasing missing sections becomes a burden, that's a good place for > >> AI > >>> — > >>>> not as a judge of code quality, but to check that required info is > >>> present > >>>> and ask for it when it isn't. > >>>> > >>>> ### On automated review feedback > >>>> > >>>> I think automated feedback is useful as one input among many, not an > >>>> authority. > >>>> > >>>> Notes about CI failures, rebases, or potential issues genuinely save > >>> time, > >>>> and even code-review comments are valuable when treated as suggestions > >> to > >>>> evaluate rather than conclusions to accept. > >>>> > >>>> I also want to acknowledge Jarek's work here. > >>>> > >>>> He's been iterating on these automated-feedback systems out in the > >> open — > >>>> trying different approaches, taking feedback as it comes, and steadily > >>>> improving them. > >>>> > >>>> I've consistently appreciated that, and I think that exact posture — > >>>> treating the tooling itself as something to evolve through community > >>>> feedback — is the right one. > >>>> > >>>> There's still room to improve, but these tools already provide real > >>> value. > >>>> > >>>> ### Closing > >>>> > >>>> I don't think we should optimize for detecting AI. > >>>> That said, it may be worth trying as one of the signals in the tool. > >>>> However, I don’t believe it will meaningfully solve the underlying > >> issue > >>> on > >>>> its own. > >>>> > >>>> We should optimize for contributors who understand their changes, can > >>>> explain their reasoning, and take responsibility for the outcome. > >>>> > >>>> That's what meaningful participation looks like, with or without AI. > >>>> > >>>> Ultimately, what we're preserving isn't code production — it's the > >>>> community. That principle holds just as strongly in the age of AI. > >>>> > >>>> Regards, > >>>> Yeonguk > >>>> > >>>> > >>>> On 2026/06/14 20:09:51 Sameer Mesiah wrote: > >>>>> Hi Przemysław, > >>>>> > >>>>> I understand that your suggestion to force new contributors to not > >> use > >>> AI > >>>>> for their first 10 contributions is meant to instil ownership in > >> them. > >>>> But > >>>>> there are 2 issues I can see with what you just said: > >>>>> > >>>>> 1) How do we define ‘AI-assisted’? There’s a broad spectrum ranging > >>> from > >>>>> leveraging LLMs to quickly upskill in a certain area you are > >> unfamiliar > >>>>> with to outright using an agentic system to submit dozens of PRs. I > >> can > >>>>> understand being against the latter as the typical outcome is AI slop > >>>> that > >>>>> is completely unreviewable. But to ban AI-assistance completely is > >> far > >>>> too > >>>>> draconian as it may increase the burden of mentorship and training on > >>> the > >>>>> maintainers. > >>>>> > >>>>> 2) If we were to adopt a harsh ban on AI completely, how would we > >>> enforce > >>>>> it? Sure, we can easily spot ‘bad’ AI-generated PRs. And, often, they > >>> end > >>>>> up getting closed en masse by a maintainer. But what about ones where > >>> AI > >>>>> was used to generate the scaffold of the PR and then heavily curated > >> by > >>>> an > >>>>> experienced engineer? How could we even detect it? > >>>>> > >>>>> I think the crux of the issue here is not AI usage (though I can > >>>> understand > >>>>> your philosophical opposition to these tools; I agree it can make the > >>>> craft > >>>>> of SWE a bit sterile) but the proliferation of > >>>>> AI slop overwhelming the project. > >>>>> > >>>>> Personally, and rather unfortunately, I think airflow may eventually > >>>> follow > >>>>> the footsteps of a few of other OSS projects that ended up > >> restricting > >>>>> contributions to a trusted inner circle. I don’t agree with it but I > >>>> sense > >>>>> that this may inevitably happen. > >>>>> > >>>>> On Sun, 14 Jun 2026 at 20:26, Przemysław Mirowski <[email protected] > >>> > >>>> wrote: > >>>>> > >>>>>> Just throwing an idea here: > >>>>>> > >>>>>> Thinking about the issue I came across this repo > >>>>>> https://github.com/mitchellh/vouch, not sure if that will be > >> helpful > >>>> or > >>>>>> not, but I strongly believe in a sentence "Open source has always > >>>> worked on > >>>>>> a system of trust and verify." which is written there. Maybe, as > >> the > >>>>>> solution and filter, Airflow should require e.g. first 10 PRs of > >> the > >>>>>> contributor to be fully written without AI usage (to build trust > >>>> between > >>>>>> Airflow community and new contributor), and automatically close PRs > >>>> which > >>>>>> were generated/co-authored by AI based on the field in PR > >> description > >>>> (or > >>>>>> sth else) and PRs quantity requirement (merged PRs, not closed or > >>>> open)? > >>>>>> > >>>>>> Idea of 10 PRs and not e.g. 1 as there can be company usage update > >> PR > >>>> and > >>>>>> potentially some other minor PRs which could be hard for building > >>>> mentioned > >>>>>> trust. > >>>>>> > >>>>>> ________________________________ > >>>>>> From: Przemysław Mirowski <[email protected]> > >>>>>> Sent: 14 June 2026 18:06 > >>>>>> To: [email protected] <[email protected]> > >>>>>> Subject: Re: Discuss/proposal: Update our AI coding policy to > >>> "forbid" > >>>>>> agents opening PRs (not banning LLM generated-code) > >>>>>> > >>>>>> Hi Kaxil, > >>>>>> > >>>>>> Responding to your question: > >>>>>> "Would you (and generally everyone here) mind sharing what folks > >> are > >>>> using > >>>>>> that field for?" with a context of "I deliberately try to not keep > >>> that > >>>>>> field in my PR descriptions. And while reviewing the PRs as well I > >> do > >>>> not > >>>>>> look at that field. As similar to what you said, it has 0 bearing > >> on > >>> my > >>>>>> code review. Either the PR is good or genuine attempt with mistakes > >>> or > >>>> pure > >>>>>> slop." > >>>>>> > >>>>>> I don't look at it when I'm starting the review or I'm in the > >> process > >>>> of > >>>>>> it. I mentioned that I don't care if the PR is generated or not, > >>>> "until the > >>>>>> quality is good and the code is fitted correctly to the project". > >> If > >>>> the PR > >>>>>> is not great, I think that we can distinct two groups of why that > >>>> happened: > >>>>>> > >>>>>> 1. > >>>>>> Author did not understand how the part of the project works, > >>>> dependencies, > >>>>>> etc. and that is the reason why the PR is not correct > >>>>>> 2. > >>>>>> Author did not see why the proposed changes are wrong as they "look > >>>> good" > >>>>>> looking at the change itself (here is the assumption that if the > >>> author > >>>>>> would have knowledge of point 1, this point would not happen) > >>>>>> > >>>>>> With point 1, we can go and ask and discuss with the person why > >>>> everything > >>>>>> with the beginning of how they though something work, make > >>> corrections, > >>>>>> etc. With point 2, it is not so easy as the person could just ask > >>>> agent, > >>>>>> "do this for me" and there was nothing behind the idea of the PR. > >> As > >>>> you > >>>>>> mentioned in one thread "Agents are very good at producing PRs with > >>> no > >>>> real > >>>>>> motivation behind them, so a human actually articulating the why > >> and > >>>> the > >>>>>> what-to-watch-for is worth more now than it ever was". The PRs > >> which > >>> I > >>>>>> called "good" are the PR which you also mentioned, even if the > >>>> description > >>>>>> or title are not fully correct, sometimes the intention is clear > >> and > >>>> if PR > >>>>>> is good, it doesn't matter what the source of it was (human or > >> not). > >>>> If the > >>>>>> PR is bad, this field and knowledge (if it was generated or not) > >> may > >>> be > >>>>>> some indicator for reviewer what was the intention of the author. > >>> This > >>>> is > >>>>>> the thing for which I use that field during or after the review. > >>> Maybe > >>>> not > >>>>>> the best one, but it is at least some input to made some more > >> correct > >>>>>> assumptions and/or decisions. > >>>>>> > >>>>>> Some additional things regarding the field itself and potential > >> usage > >>>> of > >>>>>> it (more for maintainers probably). I would say that currently PRs > >>> can > >>>> have > >>>>>> 2 sources: > >>>>>> > >>>>>> 1. > >>>>>> Fully made by human > >>>>>> 2. > >>>>>> Co-authored or generated by AI > >>>>>> > >>>>>> With everything which will be done to fight AI slop, I think that > >>> first > >>>>>> groups should not be affected (of course it can be hard sometimes, > >>> but > >>>> I > >>>>>> would say that it is a desirable goal) as we do not want to > >>> discourage > >>>>>> people who took they time to find, learn and contribute to the > >>> project. > >>>>>> Having that field filled and making sure that it is mandatory on > >>> every > >>>> PR > >>>>>> (by e.g. the check in CI which I've proposed) would make possible > >> to > >>>> build > >>>>>> statistics of PRs with separation for human/co-authored and > >> validate > >>>> how > >>>>>> new policies, guards, etc. for fighting AI slop are affecting these > >>> two > >>>>>> groups. > >>>>>> > >>>>>> Couple of other things: > >>>>>> "And we include the attribution line in AGENTS.md anyway, so any AI > >>>> agent > >>>>>> will add that line to the PR by current design" > >>>>>> > >>>>>> Agents, like every generative AI model, are not deterministic. If > >> you > >>>> do > >>>>>> not set internal random.seed and guidance value to 0 inside the > >> agent > >>>> (or > >>>>>> any generative model), it can always do different thing than you > >> want > >>>> (it > >>>>>> is a feature, not a bug; without that the generated stuff would > >>> always > >>>> be > >>>>>> the same and we want to have some variations/"creativity" during > >>>>>> generation). Using all skills, etc. is making this less probable, > >> but > >>>> not > >>>>>> impossible (e.g. the case mentioned by Ash with user mention in PR > >>>> comment). > >>>>>> > >>>>>> "Maybe - we can start discussing on a "complete" change there - I.a > >>> PR > >>>>>> with a description of the expected process and even maybe showing > >> the > >>>>>> expected "flow" of contribution we want to have - with/without AI > >> and > >>>> wiht > >>>>>> assistance rather than with no human involvement. I think it would > >> be > >>>> great > >>>>>> to describe it and discuss it - knowing what happens where and also > >>>> connect > >>>>>> it with "what happens next" - i.e. we will not improve our > >> experience > >>>> (and > >>>>>> experience of our contributors) if we do not think about the > >>>> contribution > >>>>>> process end-2-end - we not only have to set expectations for our > >>>>>> contributors, but we also have to be clear what they should expect > >>>> from us > >>>>>> - becasue this human - human relation works both ways." > >>>>>> > >>>>>> If that wasn't done before, I would say +1, but I think that some > >>>> level of > >>>>>> flexibility is desirable. Regarding the possible ways - I don't > >> have > >>>> any > >>>>>> idea or opinion. Maybe some different open-source projects which > >> are > >>>> bigger > >>>>>> than Airflow created something for managing high PRs number more > >>>>>> efficiently like Linux or Python projects (I don't know how stuff > >>> works > >>>>>> there, but maybe there is something which could be an inspiration > >> for > >>>>>> Airflow community). > >>>>>> > >>>>>> Best, > >>>>>> Przemek > >>>>>> ________________________________ > >>>>>> From: Jarek Potiuk <[email protected]> > >>>>>> Sent: 14 June 2026 12:17 > >>>>>> To: [email protected] <[email protected]> > >>>>>> Subject: Re: Discuss/proposal: Update our AI coding policy to > >>> "forbid" > >>>>>> agents opening PRs (not banning LLM generated-code) > >>>>>> > >>>>>> Yes. The https://www.apache.org/legal/generative-tooling.html is > >> the > >>>>>> decisive factor here. And it's not only a "cargo cult" of some > >> sort, > >>>>>> but a real legal expectation (not mandatory but strongly suggested) > >>>>>> expectation. This is mostly because it allows us to avoid > >> attempting > >>>>>> to track provenance in case of any kind of legal disputes when the > >>>>>> matter—for example, using Gen AI trained on GPL software—is > >> settled. > >>>>>> For now those disputes are not yet settled - though there are > >> already > >>>>>> some signs showing that "GenAI" is not going to be treated the same > >>> as > >>>>>> "Copying" - so copyright and licences related to copyright have no > >>>>>> impact here (again - not settled yet). > >>>>>> > >>>>>> And I agree with Shahar that introducing a bit of "friction" in the > >>>>>> process - and especially doing everything to slow things down while > >>>>>> removing things that should not take our attention is important. > >>>>>> > >>>>>> Maybe - we can start discussing on a "complete" change there - I.a > >> PR > >>>>>> with a description of the expected process and even maybe showing > >> the > >>>>>> expected "flow" of contribution we want to have - with/without AI > >> and > >>>>>> wiht assistance rather than with no human involvement. I think it > >>>>>> would be great to describe it and discuss it - knowing what happens > >>>>>> where and also connect it with "what happens next" - i.e. we will > >> not > >>>>>> improve our experience (and experience of our contributors) if we > >> do > >>>>>> not think about the contribution process end-2-end - we not only > >> have > >>>>>> to set expectations for our contributors, but we also have to be > >>> clear > >>>>>> what they should expect from us - becasue this human - human > >> relation > >>>>>> works both ways. > >>>>>> > >>>>>> J. > >>>>>> > >>>>>> On Sun, Jun 14, 2026 at 7:16 AM Shahar Epstein <[email protected]> > >>>> wrote: > >>>>>>> > >>>>>>> To put things into context, adding the checkbox was discussed > >>>>>>> < > >> https://lists.apache.org/thread/s5pchk082wpqro8vk400c7wv5jhsbvwg> > >>>> on > >>>>>> the > >>>>>>> devlist and agreed upon by a lazy cocensus > >>>>>>> < > >> https://lists.apache.org/thread/9b19dcbcdb41ngw0jqgzcsrtrxl0v34c > >>>> . > >>>>>>> > >>>>>>> tl;dr - why we need it: > >>>>>>> - Reduce reviewer burden (it was introduced at the time when we > >>> were > >>>>>>> overwhelmed with AI slop) > >>>>>>> - Increase transparency > >>>>>>> - Preserve ownership > >>>>>>> - Legal considerations > >>>>>>> <https://www.apache.org/legal/generative-tooling.html> (was > >>> briefly > >>>>>>> mentioned as part of the proposed template, but I think that > >> it's a > >>>>>> serious > >>>>>>> matter for the project's future health) > >>>>>>> > >>>>>>> I don't think that comparison to what we used to do in the past > >> is > >>>>>>> "apples-to-apples". > >>>>>>> We're in a very different state in terms of community size, > >> number > >>> of > >>>>>>> releases, and now we're at the beginning of an AI revolution. > >>>>>>> So asking contributors to add a short description to ensure that > >>>> they're > >>>>>>> aware of and own the changes they proposed is a blessing (and > >> not a > >>>> big > >>>>>>> deal, IMO - eventually it's a matter of copying-pasting-stylizing > >>> the > >>>>>>> prompt that they had just given to the AI moments before creating > >>> the > >>>>>> PR). > >>>>>>> From another perspective, now that release managers use AI > >> tooling > >>> to > >>>>>>> cherry-pick and/or describe changes in the changelog, it is even > >>> more > >>>>>>> important that PRs are well-summarized - to help them with the > >>>> release, > >>>>>> as > >>>>>>> the number of PRs has nicely grown overtime - but there's usually > >>> one > >>>>>>> release manager that handles them in each release. > >>>>>>> > >>>>>>> > >>>>>>> Shahar > >>>>>>> > >>>>>>> > >>>>>>> On Sun, Jun 14, 2026 at 4:00 AM Kaxil Naik <[email protected]> > >>>> wrote: > >>>>>>> > >>>>>>>> Hi Przemsyslaw, > >>>>>>>> > >>>>>>>> Thanks for the nudge for not keeping the GenAI checkbox on > >>>>>>>> https://github.com/apache/airflow/pull/68492 > >>>>>>>> . > >>>>>>>> > >>>>>>>> Would you (and generally everyone here) mind sharing what folks > >>> are > >>>>>> using > >>>>>>>> that field for? > >>>>>>>> > >>>>>>>> I deliberately try to not keep that field in my PR > >> descriptions. > >>>> And > >>>>>> while > >>>>>>>> reviewing the PRs as well I do not look at that field. As > >> similar > >>>> to > >>>>>> what > >>>>>>>> you said, it has 0 bearing on my code review. Either the PR is > >>>> good or > >>>>>>>> genuine attempt with mistakes or pure slop. > >>>>>>>> > >>>>>>>> My read (which can obviously be just my own interpretation) is > >>> that > >>>>>> those > >>>>>>>> are guidelines and could help spot drive-by new contributors > >> who > >>>> in an > >>>>>>>> attempt to create stars for their GitHub profile, create > >> genuine > >>>> slop > >>>>>> with > >>>>>>>> 0 project understanding. For committers on the other hand, they > >>> are > >>>>>> well > >>>>>>>> aware and have knowledge of the working of the project. Hence, > >>>> those > >>>>>> are > >>>>>>>> guidelines and are not rules. I can keep the checkbox on my PR > >>> but > >>>> I > >>>>>> don’t > >>>>>>>> think it would serve any purpose. And we include the > >> attribution > >>>> line > >>>>>> in > >>>>>>>> AGENTS.md anyway, so any AI agent will add that line to the PR > >> by > >>>>>> current > >>>>>>>> design. So that isn’t going to help if we plan or decide to use > >>>> that to > >>>>>>>> classify AI slop. > >>>>>>>> > >>>>>>>> I have closed probably 50+ PRs over last several months on the > >>>> Airflow > >>>>>> repo > >>>>>>>> to close sloppy PRs but haven’t used that field to judge that > >> but > >>>> more > >>>>>> the > >>>>>>>> pattern of several PRs, unrelated changes, lack of response > >> when > >>>> asked > >>>>>> with > >>>>>>>> technical questions etc were the reason. > >>>>>>>> > >>>>>>>> Over Airflow’s history of last 10-11 years, the PR description > >>>>>> template has > >>>>>>>> undergone various incarnation. > >>>>>>>> https://github.com/apache/airflow/pull/2810 Is an example of > >> my > >>>>>> simple PR > >>>>>>>> - > >>>>>>>> 9 years ago. And while it looks closed, it isn’t:) we just used > >>>>>> different > >>>>>>>> mechanism to merge changes to main. And this PR was merged. And > >>>> lessons > >>>>>>>> from all those years was to know the motivation behind the PR > >> and > >>>> any > >>>>>>>> gotchas. We have had several PRs with no descriptions at all > >> but > >>> I > >>>>>> might > >>>>>>>> have merged them as well as it was just too evident from the PR > >>>> title. > >>>>>>>> > >>>>>>>> So my recommendation would not be to add/need anything in PR > >>>>>> description > >>>>>>>> which we aren’t going to use to determine something from it. If > >>>> we’d > >>>>>> like > >>>>>>>> to do any test like the one suggested in thread email, i.e some > >>>> action > >>>>>>>> based on the failure of the test, I am fine with it. > >>>>>>>> > >>>>>>>> Regards, > >>>>>>>> Kaxil > >>>>>>>> > >>>>>>>> On Sat, 13 Jun 2026 at 13:42, Przemysław Mirowski < > >>>> [email protected]> > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> Hello everyone, > >>>>>>>>> > >>>>>>>>> For the start, this message can be a little out of context of > >>>> this > >>>>>>>>> discussion (sorry about that), but as it touches the AI usage > >>> on > >>>> the > >>>>>>>>> Airflow project, I felt that it may be worth it to add my 2c > >>>> here. > >>>>>>>>> > >>>>>>>>> As for the context - I don't use AI to do any coding, prepare > >>>> PRs, > >>>>>> review > >>>>>>>>> the code. I don't use it also in other areas in my life as a > >>>>>>>> contradiction > >>>>>>>>> to the fact that I did some science research on AI in couple > >> of > >>>> areas > >>>>>>>> e.g. > >>>>>>>>> medicine. I don't use it mainly from 2 reasons: > >>>>>>>>> > >>>>>>>>> 1. > >>>>>>>>> I don't trust AI - any generative model can generate stuff > >>> which > >>>> are > >>>>>> not > >>>>>>>>> true and most of the time, AI is pretty convinced that it is > >>>> right, > >>>>>> when > >>>>>>>> it > >>>>>>>>> is not > >>>>>>>>> 2. > >>>>>>>>> I believe that Software Engineering is a craft which I just > >>> like > >>>>>> doing > >>>>>>>> and > >>>>>>>>> getting better in it. Using any AI, will not make my > >>>> craftsmanship > >>>>>>>> better. > >>>>>>>>> In the contrary, it will made me dependent on the tool and > >> will > >>>> not > >>>>>> make > >>>>>>>> me > >>>>>>>>> exercise my understanding on multiple levels of Software > >>>> Engineering > >>>>>> as > >>>>>>>> the > >>>>>>>>> design decisions will be proposed by the model and not the > >>>> result of > >>>>>> my > >>>>>>>>> thoughts and understanding of the issue. Now I can write > >>>> anything, > >>>>>> with > >>>>>>>>> using AI to generate code for 3 years straight, I don't > >> believe > >>>> that > >>>>>> I > >>>>>>>>> could write same quality of code or maybe I would not be able > >>> to > >>>>>> write > >>>>>>>>> anything after that long time > >>>>>>>>> > >>>>>>>>> Of course there are more reasons like climate-related stuff, > >>> but > >>>>>> these > >>>>>>>> two > >>>>>>>>> are the most important for me. > >>>>>>>>> > >>>>>>>>> I am the Apache Airflow contributor for some time now and in > >>>>>> majority of > >>>>>>>>> cases, I'm involved in the Helm Chart area. As there are not > >>> many > >>>>>> things > >>>>>>>>> going on there, the PRs number is low. As there was not many > >>>>>> interest in > >>>>>>>>> the Helm Chart in the past, I started doing review to > >>> potentially > >>>>>> make > >>>>>>>> PRs > >>>>>>>>> "ready for maintainer" review to, maybe, make Helm Chart > >> alive > >>>>>> again. Due > >>>>>>>>> to all AI-stuff going on since some time now, I'm doing less > >>>> review > >>>>>> and > >>>>>>>> it > >>>>>>>>> takes longer time. Not because I'm less committed to the > >>> project > >>>> or I > >>>>>>>> don't > >>>>>>>>> like AI or anything. Personally, who wrote the code (human or > >>>> AI) it > >>>>>>>>> doesn't really matter for me, until the quality is good and > >> the > >>>> code > >>>>>> is > >>>>>>>>> fitted correctly to the project and does not break e.g. > >>>> consistency > >>>>>> of > >>>>>>>> it. > >>>>>>>>> What I see in the Helm Chart-related PRs is that people do > >> not > >>>>>> review the > >>>>>>>>> code which they commit and, in most cases, when the e.g. helm > >>>>>> template > >>>>>>>>> logic is not perfect, but good enough for me to press > >>> "Approve", > >>>> the > >>>>>> test > >>>>>>>>> cases are just out of the place e.g. in terms of quality, > >>>>>> consistency or > >>>>>>>>> even duplication (same test case already exists somewhere in > >>> the > >>>> test > >>>>>>>> suite > >>>>>>>>> and new one is proposed). For me this is really discouraging, > >>>>>> because it > >>>>>>>>> basically kills "Community over Code" which is the core of > >> the > >>>> Apache > >>>>>>>>> Software Foundation which was part of my decision why I've > >> got > >>>>>> involved > >>>>>>>> in > >>>>>>>>> the project. > >>>>>>>>> > >>>>>>>>> But, keeping some more relevance to the thread itself, I > >> would > >>>> ask > >>>>>> you, > >>>>>>>> as > >>>>>>>>> the Maintainers of the project, to slow down a bit. I feel > >> like > >>>> past > >>>>>> 2-3 > >>>>>>>>> months was like a sprint to try to solve the issue and > >> looking > >>> at > >>>>>> some > >>>>>>>> PRs, > >>>>>>>>> comments and discussions on the devlist, I think that some > >>>> things are > >>>>>>>>> tested too quickly on too big scale, which impacts both > >>>> Maintainers > >>>>>> and > >>>>>>>>> Contributors of the project. I believe that nobody knows how > >> to > >>>>>> resolve > >>>>>>>>> current situation but taking some actions can be discouraging > >>> for > >>>>>> current > >>>>>>>>> or future contributors (first PR which came up to my mind - > >>>>>>>>> https://github.com/apache/airflow/pull/61039). Just take one > >>>> step > >>>>>> at the > >>>>>>>>> time. I think that moving just faster will not resolve this > >>>> issue. > >>>>>>>>> > >>>>>>>>> +1 for the Shahar proposal regarding the new PR Template. I > >>> would > >>>>>> add to > >>>>>>>>> it the gate in the CI for validation of the description e.g. > >> if > >>>>>>>> everything > >>>>>>>>> is visible as it should be (I noticed that a lot of PRs do > >> not > >>>> have > >>>>>> "Was > >>>>>>>>> generative AI tooling..." part in desc e.g. > >>>>>>>>> https://github.com/apache/airflow/pull/68492). > >>>>>>>>> > >>>>>>>>> P.S. For anyone interested the starting point for this > >> message > >>>> was > >>>>>>>>> https://github.com/apache/airflow/pull/68074 PR. > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Przemek > >>>>>>>>> ________________________________ > >>>>>>>>> From: Jarek Potiuk <[email protected]> > >>>>>>>>> Sent: 12 June 2026 16:47 > >>>>>>>>> To: [email protected] <[email protected]> > >>>>>>>>> Subject: Re: Discuss/proposal: Update our AI coding policy to > >>>>>> "forbid" > >>>>>>>>> agents opening PRs (not banning LLM generated-code) > >>>>>>>>> > >>>>>>>>> Hello everyone, > >>>>>>>>> > >>>>>>>>> I’m happy to share that I’ve implemented and tested a new > >>>> iteration > >>>>>> of > >>>>>>>> our > >>>>>>>>> triage process based on your feedback! I hope this will help > >>> us > >>>> to > >>>>>>>>> continue getting benefits from the triage (100s of drive-by > >> PRs > >>>>>> moved out > >>>>>>>>> of the pile, plus useful guidance to some human new > >>>> collaborators) + > >>>>>>>>> opportunity to automate deterministic parts in CI and > >>>> continuously > >>>>>> refine > >>>>>>>>> it will be a good start to make more improvements. > >>>>>>>>> > >>>>>>>>> I hope this stabilizes things so we can move forward next > >> with > >>>> the PR > >>>>>>>>> template updates and review process (as next steps) and help > >>>> clear > >>>>>> the > >>>>>>>>> maintainer review queue together. > >>>>>>>>> > >>>>>>>>> Here’s a look at what’s new: > >>>>>>>>> > >>>>>>>>> 1. Focused Communication: I’ve replaced repetitive comments > >>>> with a > >>>>>>>>> single, updateable description in the PR. It keeps track of > >> the > >>>>>> latest > >>>>>>>>> status and responsible party, letting authors know exactly > >> when > >>>> they > >>>>>> are > >>>>>>>>> "ready for review." > >>>>>>>>> 2. Helpful Notifications: Authors are now assigned when > >> action > >>>> is > >>>>>> needed > >>>>>>>>> and unassigned once ready, ensuring they get the right > >>>> notifications > >>>>>> at > >>>>>>>> the > >>>>>>>>> right time. > >>>>>>>>> 3. Smarter Mentions: A new Python script (in deterministic > >>>> hooks) > >>>>>>>> ensures > >>>>>>>>> maintainer IDs are formatted correctly - with (`@id` in > >>>> backticks) to > >>>>>>>>> prevent any accidental pings. > >>>>>>>>> 4. Approachable Tone: Comments are now shorter and more > >>> direct, > >>>>>>>> balancing > >>>>>>>>> friendly guidance with our expectations. > >>>>>>>>> 5. Reliability: The workflow remains consistent while making > >>>>>>>>> responsibility even clearer for everyone. > >>>>>>>>> > >>>>>>>>> I’m still gathering stats to see what we can automate in the > >> CI > >>>> soon. > >>>>>>>>> Today’s triage (66 actions out of 500) shows that more PRs > >> are > >>>>>> passing > >>>>>>>> our > >>>>>>>>> criteria than being filtered out—which confirms that our main > >>>> goal is > >>>>>>>>> simply making the most of our human attention! > >>>>>>>>> > >>>>>>>>> Triage Summary: > >>>>>>>>> > >>>>>>>>> * mark-ready: 21 > >>>>>>>>> * workflow-approvals: 20 > >>>>>>>>> * reruns: 3 > >>>>>>>>> * violation folds (draft/comment): 7 > >>>>>>>>> * request-author-confirmation: 4 > >>>>>>>>> * pings: 4 > >>>>>>>>> * stale-draft closes: 5 > >>>>>>>>> > >>>>>>>>> You can see the new notes in action here for example > >>>> (screenshots are > >>>>>>>> also > >>>>>>>>> attached): https://github.com/apache/airflow/pull/67790 > >>>>>>>>> > >>>>>>>>> I hope we can continue refining it together, and I think that > >>>> thread > >>>>>> was > >>>>>>>> a > >>>>>>>>> good opportunity to surface some of the issues. > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Jarek > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> On Thu, Jun 11, 2026 at 3:32 PM 김준영 <[email protected] > >>>> <mailto: > >>>>>>>>> [email protected]>> wrote: > >>>>>>>>> That makes a lot of sense — thanks for taking the time to > >>>> explain the > >>>>>>>>> reasoning in detail. I have a much better understanding of > >> the > >>>>>>>>> project's philosophy now. > >>>>>>>>> > >>>>>>>>> Junyeong Kim > >>>>>>>>> > >>>>>>>>> 2026년 6월 11일 (목) 오후 10:27, Jarek Potiuk <[email protected] > >>>> <mailto: > >>>>>>>>> [email protected]>>님이 작성: > >>>>>>>>>> > >>>>>>>>>> That said, I think the key distinction is who controls the > >>>> assignee > >>>>>>>>>> slot. Rather than contributors (or agents) requesting > >>>> assignment, > >>>>>> what > >>>>>>>>>> if maintainers were the ones to grant it — based on their > >> own > >>>>>> current > >>>>>>>>>> capacity? Each maintainer could self-regulate how many > >> issues > >>>>>> they're > >>>>>>>>>> actively triaging at a given time. Even if agents flood the > >>>> queue > >>>>>> with > >>>>>>>>>> requests, nothing moves forward without a maintainer > >> actively > >>>>>> choosing > >>>>>>>>>> to open a slot. > >>>>>>>>>> > >>>>>>>>>> This is precisely the point. We want to cut the noise, not > >>> add > >>>>>> more. A > >>>>>>>>>> maintainer mechanically assigning an assignee to the person > >>>>>> requesting > >>>>>>>> it > >>>>>>>>>> is precisely what we do not want to do. Especially since we > >>>> have > >>>>>> no way > >>>>>>>>> of > >>>>>>>>>> knowing whether the person requesting it is a real person > >> or > >>> a > >>>> bot. > >>>>>>>> It's > >>>>>>>>>> really not a problem to have several people (or agents) > >>>> working on > >>>>>> the > >>>>>>>>> same > >>>>>>>>>> issue simultaneously. We even prefer people opening PRs > >>> without > >>>>>> prior > >>>>>>>>>> issues, and really de-duplication of that work is not a > >> goal > >>>> for > >>>>>> us. > >>>>>>>>>> Contributors working on the same thing in parallel will > >>> learn - > >>>>>> even > >>>>>>>> from > >>>>>>>>>> others doing parallel implementation (if they are humans) > >> or > >>>> lose > >>>>>> their > >>>>>>>>> own > >>>>>>>>>> tokens (if they are agents. We care about people learning, > >> we > >>>> do > >>>>>> not > >>>>>>>> care > >>>>>>>>>> about others directing their tokens into whatever they feel > >>>> they > >>>>>> want. > >>>>>>>>>> > >>>>>>>>>> In short - at least as I see it (but I would love to hear > >>>>>>>>> others)—handling > >>>>>>>>>> assignments manually adds maintainers more (dull and > >>> completely > >>>>>>>>> mechanical) > >>>>>>>>>> work, while freeing people using agents without > >> understanding > >>>> the > >>>>>>>>> workflow > >>>>>>>>>> to save their tokens and spam us even more. It also gives > >>> them > >>>>>> fewer > >>>>>>>>>> opportunities to learn, so it's not worth it—only losses, > >> no > >>>> gains. > >>>>>>>>>> > >>>>>>>>>> On Thu, Jun 11, 2026 at 2:17 PM 김준영 < > >> [email protected] > >>>>>> <mailto: > >>>>>>>>> [email protected]>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Subject: Re: [DISCUSS] Agents opening PRs > >>>>>>>>>>> > >>>>>>>>>>> Hi Jarek, > >>>>>>>>>>> > >>>>>>>>>>> Thanks for the thoughtful response — the point about > >> agents > >>>>>> instantly > >>>>>>>>>>> re-requesting assignment is a real concern. > >>>>>>>>>>> > >>>>>>>>>>> That said, I think the key distinction is who controls > >> the > >>>>>> assignee > >>>>>>>>>>> slot. Rather than contributors (or agents) requesting > >>>> assignment, > >>>>>>>> what > >>>>>>>>>>> if maintainers were the ones to grant it — based on their > >>> own > >>>>>> current > >>>>>>>>>>> capacity? Each maintainer could self-regulate how many > >>> issues > >>>>>> they're > >>>>>>>>>>> actively triaging at a given time. Even if agents flood > >> the > >>>> queue > >>>>>>>> with > >>>>>>>>>>> requests, nothing moves forward without a maintainer > >>> actively > >>>>>>>> choosing > >>>>>>>>>>> to open a slot. > >>>>>>>>>>> > >>>>>>>>>>> This shifts the bottleneck to maintainer bandwidth, which > >>> is > >>>>>> already > >>>>>>>>>>> the real constraint anyway. And it naturally filters > >> signal > >>>> from > >>>>>>>> noise > >>>>>>>>>>> — maintainers would prioritize issues worth acting on. > >>>>>>>>>>> > >>>>>>>>>>> Could that be a workable middle ground? > >>>>>>>>>>> > >>>>>>>>>>> Junyeong Kim > >>>>>>>>>>> > >>>>>>>>>>> 2026년 6월 11일 (목) 오후 9:07, Jarek Potiuk <[email protected] > >>>> <mailto: > >>>>>>>>> [email protected]>>님이 작성: > >>>>>>>>>>>> > >>>>>>>>>>>> Hi everyone, > >>>>>>>>>>>> > >>>>>>>>>>>> Just a quick update that’s quite relevant to this > >>>> discussion > >>>>>> and > >>>>>>>>> Ash’s > >>>>>>>>>>>> concerns about AGENTS.md. I had a great call yesterday > >>> with > >>>>>> Jason > >>>>>>>>> and our > >>>>>>>>>>>> GSoC intern, Roy. We’ve decided to focus his internship > >>> on > >>>>>>>> optimizing > >>>>>>>>>>>> AGENTS.md by extracting key sections and defining evals > >>> for > >>>>>> them, > >>>>>>>>>>> inspired > >>>>>>>>>>>> by the mini-eval framework in Magpie. This should help > >>>> make our > >>>>>>>>> agentic > >>>>>>>>>>>> instructions much more deterministic. Since agents can > >>>> struggle > >>>>>>>> with > >>>>>>>>> very > >>>>>>>>>>>> long instructions, splitting these into smaller, > >> focused > >>>>>> "skills" > >>>>>>>>> should > >>>>>>>>>>>> really help them follow our guidelines more reliably. > >>>>>>>>>>>> > >>>>>>>>>>>> We’ll share a formal announcement on the devlist soon. > >>> I’d > >>>>>> love for > >>>>>>>>> us > >>>>>>>>>>> all > >>>>>>>>>>>> to jump in on the reviews—it’s a great chance for us to > >>>> learn > >>>>>>>>> together > >>>>>>>>>>>> about agent limitations and how to better manage them. > >>>>>>>>>>>> > >>>>>>>>>>>> Junyeong, thanks for the suggestion on reintroducing > >>>>>> assignments. > >>>>>>>>> While I > >>>>>>>>>>>> understand the intent, I'm a little worried it might > >>>> backfire. > >>>>>> In > >>>>>>>> the > >>>>>>>>>>> past, > >>>>>>>>>>>> "assign and disappear" was a challenge, but my bigger > >>>> concern > >>>>>> now > >>>>>>>> is > >>>>>>>>> that > >>>>>>>>>>>> agents can "request assignment" almost instantly after > >>>>>> de-assigning > >>>>>>>>> and > >>>>>>>>>>>> practically for free (deterministically). Previously, > >>>>>> requesting > >>>>>>>>>>>> assignments created a lot of noise and required > >>>> maintainers to > >>>>>> act. > >>>>>>>>>>>> However, even if we automate this - like some other > >>>>>> projects—agents > >>>>>>>>> could > >>>>>>>>>>>> effectively block issues indefinitely, making it much > >>>> harder > >>>>>> for > >>>>>>>> real > >>>>>>>>>>> human > >>>>>>>>>>>> contributors to find an opening. > >>>>>>>>>>>> > >>>>>>>>>>>> But - looking forward to hearing more thoughts. > >>>>>>>>>>>> > >>>>>>>>>>>> Best regards, > >>>>>>>>>>>> > >>>>>>>>>>>> Jarek > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Thu, Jun 11, 2026 at 1:39 AM 김준영 < > >>>> [email protected] > >>>>>>>> <mailto: > >>>>>>>>> [email protected]>> wrote: > >>>>>>>>>>>> > >>>>>>>>>>>>> Hi all, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks for the discussion — as a contributor, I've > >>> found > >>>> it > >>>>>>>> really > >>>>>>>>>>>>> helpful to understand how maintainers are thinking > >>> about > >>>>>> this. > >>>>>>>>>>>>> > >>>>>>>>>>>>> One thing I've noticed from the contributor side: > >>>> without an > >>>>>>>>> assignee > >>>>>>>>>>>>> system, there's no clear signal at the issue level > >> that > >>>>>> someone > >>>>>>>> is > >>>>>>>>>>>>> already working on something. That lower friction > >> might > >>>> be > >>>>>> part > >>>>>>>> of > >>>>>>>>>>>>> what's making it easier for agent-driven PRs to slip > >>>> through > >>>>>>>>> without > >>>>>>>>>>>>> prior discussion. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'm not sure of the full history behind removing > >>>> assignees, > >>>>>> but I > >>>>>>>>>>>>> wonder if the original "assign and abandon" problem > >>> could > >>>>>> have > >>>>>>>> been > >>>>>>>>>>>>> addressed with an auto-unassign policy (e.g. 2 weeks > >> of > >>>>>>>> inactivity) > >>>>>>>>>>>>> rather than removing the system entirely. > >> Reintroducing > >>>>>> assignees > >>>>>>>>> with > >>>>>>>>>>>>> that kind of timeout might act as an upstream > >>> complement > >>>> to > >>>>>> the > >>>>>>>>>>>>> PR-level checks being discussed here. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Could that be worth revisiting alongside Jarek's > >>>> proposal? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Junyeong Kim > >>>>>>>>>>>>> > >>>>>>>>>>>>> 2026년 6월 11일 (목) 오전 8:20, Jarek Potiuk < > >>> [email protected] > >>>>>> <mailto: > >>>>>>>>> [email protected]>>님이 작성: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I was watching the mail train and I think that > >>> sounds > >>>>>> good. > >>>>>>>>> Hope > >>>>>>>>>>> the > >>>>>>>>>>>>>>> check can be made early e.g. during build info > >> and > >>> if > >>>>>>>> possible > >>>>>>>>> can > >>>>>>>>>>> we > >>>>>>>>>>>>>>> (once setting to DRAFT) kill all successor steps > >> to > >>>> save > >>>>>> CI > >>>>>>>>>>> capacity? > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Excellent idea - absolutely, we can build it into > >>>>>>>>> "selective-checks" > >>>>>>>>>>> to > >>>>>>>>>>>>>> "fail" and make a clear statement during failure. I > >>>> hadn't > >>>>>>>>> thought of > >>>>>>>>>>>>> that. > >>>>>>>>>>>>>> There were some ideas about "pull_request_target", > >>> but > >>>>>> yes, you > >>>>>>>>> are > >>>>>>>>>>>>>> completely right - all that checks are > >> deterministic > >>>> and > >>>>>> can be > >>>>>>>>> part > >>>>>>>>>>> of > >>>>>>>>>>>>> the > >>>>>>>>>>>>>> "buid info" job that we use to determine what to do > >>>> with > >>>>>> the > >>>>>>>> PR. > >>>>>>>>>>> Should > >>>>>>>>>>>>> be > >>>>>>>>>>>>>> very simple. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On Wed, Jun 10, 2026 at 8:43 PM Jens Scheffler < > >>>>>>>>> [email protected]<mailto:[email protected]>> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I was watching the mail train and I think that > >>> sounds > >>>>>> good. > >>>>>>>>> Hope > >>>>>>>>>>> the > >>>>>>>>>>>>>>> check can be made early e.g. during build info > >> and > >>> if > >>>>>>>> possible > >>>>>>>>> can > >>>>>>>>>>> we > >>>>>>>>>>>>>>> (once setting to DRAFT) kill all successor steps > >> to > >>>> save > >>>>>> CI > >>>>>>>>>>> capacity? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Otherwise I hope we can most constructive, not > >>>> "Fighting > >>>>>> fire > >>>>>>>>> with > >>>>>>>>>>>>> fire" > >>>>>>>>>>>>>>> but rather aim to improve agent descriptions to > >>>> optimize > >>>>>>>>> other's > >>>>>>>>>>> token > >>>>>>>>>>>>>>> budgets in favor of our requirements. We can not > >>> turn > >>>>>> back > >>>>>>>>> time and > >>>>>>>>>>>>> need > >>>>>>>>>>>>>>> to assume the level of agent contributions will > >>> stay > >>>>>> forever > >>>>>>>> in > >>>>>>>>>>> future. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Jens > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On 10.06.26 08:55, Jarek Potiuk wrote: > >>>>>>>>>>>>>>>> Hi everyone, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I’ve spent some time reflecting on all the > >> great > >>>> points > >>>>>>>>> raised > >>>>>>>>>>> here. > >>>>>>>>>>>>> Our > >>>>>>>>>>>>>>>> shared goals are to ensure human ownership and > >>>> review, > >>>>>> keep > >>>>>>>>>>> agents as > >>>>>>>>>>>>>>>> helpful assistants rather than sole authors, > >> and > >>>>>> reduce the > >>>>>>>>>>> cognitive > >>>>>>>>>>>>>>> load > >>>>>>>>>>>>>>>> from long AI-generated descriptions. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I really like Shahar's proposal and would love > >> to > >>>>>> build on > >>>>>>>> it > >>>>>>>>>>> with a > >>>>>>>>>>>>> few > >>>>>>>>>>>>>>>> suggestions to make our expectations clear and > >>>>>> supportive > >>>>>>>>> for our > >>>>>>>>>>>>> human > >>>>>>>>>>>>>>>> contributors: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> - Explicit Instructions: Let’s be very open > >> in > >>>> our > >>>>>>>>> templates > >>>>>>>>>>> and > >>>>>>>>>>>>>>>> AGENTS.md. We can instruct agents to pause and > >>> ask > >>>> the > >>>>>>>> human > >>>>>>>>> to > >>>>>>>>>>>>> write the > >>>>>>>>>>>>>>>> description, noting that this personal touch is > >>>>>> essential > >>>>>>>> for > >>>>>>>>>>> the PR > >>>>>>>>>>>>> to > >>>>>>>>>>>>>>>> stay open. > >>>>>>>>>>>>>>>> - Human Review Checkbox: I suggest adding a > >>>>>> checkbox: "- > >>>>>>>>> [ ] I > >>>>>>>>>>>>> have > >>>>>>>>>>>>>>>> reviewed this code myself." We’ll instruct > >> agents > >>>> to > >>>>>> leave > >>>>>>>>> this > >>>>>>>>>>> for > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>> human to check, ensuring that vital moment of > >>>>>> reflection. > >>>>>>>>>>>>>>>> - Instead of copy-pasting (which I find > >>>> awkward), > >>>>>> we can > >>>>>>>>>>> instruct > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>> agents to use `gh --web`, `--template` (to > >>> include > >>>> the > >>>>>>>>>>> template), and > >>>>>>>>>>>>>>>> `--draft` (following Pierre's idea). This > >> creates > >>>>>> natural > >>>>>>>>>>>>>>>> checkpoints—filling the description, checking > >> the > >>>> box, > >>>>>>>>> clicking > >>>>>>>>>>>>> submit, > >>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>> undrafting—that encourage human involvement. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> We should also state the consequences for > >>>>>> non-compliance: > >>>>>>>> To > >>>>>>>>>>> keep our > >>>>>>>>>>>>>>> queue > >>>>>>>>>>>>>>>> healthy, we should use an automated process to > >>>> close > >>>>>> PRs > >>>>>>>> that > >>>>>>>>>>> miss > >>>>>>>>>>>>> these > >>>>>>>>>>>>>>>> steps, with a note explaining how to resubmit > >>> them > >>>> with > >>>>>>>> human > >>>>>>>>>>> input. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> All those expectations and closing etc. should > >> be > >>>>>> equally > >>>>>>>>>>> applied to > >>>>>>>>>>>>> all > >>>>>>>>>>>>>>>> PRs, including maintainer PRs. This will also > >>> allow > >>>>>> those > >>>>>>>> of > >>>>>>>>> us > >>>>>>>>>>> who > >>>>>>>>>>>>> use > >>>>>>>>>>>>>>>> agents to monitor the process and refine the > >>>>>> instructions > >>>>>>>> if > >>>>>>>>> we > >>>>>>>>>>> see > >>>>>>>>>>>>> any > >>>>>>>>>>>>>>>> loopholes that agents try to bypass or learn > >> how > >>> to > >>>>>>>>> circumvent. > >>>>>>>>>>> This > >>>>>>>>>>>>> will > >>>>>>>>>>>>>>>> allow us to continuously improve the process. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I believe this approach balances productivity > >>> with > >>>> the > >>>>>>>>>>> high-quality > >>>>>>>>>>>>> human > >>>>>>>>>>>>>>>> collaboration we all value. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> What do you think? > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Jarek > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Tue, Jun 9, 2026 at 5:00 PM Shahar Epstein < > >>>>>>>>> [email protected]<mailto:[email protected]> > >>>>>>>>>>>> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Here's a more concrete suggestion: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Updating the PR template in such a way that: > >>>>>>>>>>>>>>>>> 1. Human summary is now a MUST - at least a > >>>> oneliner* > >>>>>> (or > >>>>>>>>> more, > >>>>>>>>>>>>>>> depending > >>>>>>>>>>>>>>>>> on the scope - TBD) that describes the > >> suggested > >>>>>> changes > >>>>>>>>>>> written by > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>> PR's author themselves (without AI > >> assistance). > >>>>>>>>>>>>>>>>> 2. AI summary is optional. However, when > >>> included > >>>> - it > >>>>>>>> MUST > >>>>>>>>> be > >>>>>>>>>>> bound > >>>>>>>>>>>>>>> within > >>>>>>>>>>>>>>>>> a collapsible box, mainly to save cognitive > >> load > >>>> for > >>>>>>>>>>> maintainers and > >>>>>>>>>>>>>>>>> contributors, but also to encourage human > >>>> interaction > >>>>>> like > >>>>>>>>> we > >>>>>>>>>>> used > >>>>>>>>>>>>> to do > >>>>>>>>>>>>>>>>> before it all started. > >>>>>>>>>>>>>>>>> 3. PR's author (human) should be the one > >>> declaring > >>>>>> the AI > >>>>>>>>> usage > >>>>>>>>>>>>>>> checkbox - > >>>>>>>>>>>>>>>>> added a short statement of ownership. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Contributors will be instructed to use this > >>>> template > >>>>>> and > >>>>>>>>> adhere > >>>>>>>>>>> to > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>> instructions when creating a PR. > >>>>>>>>>>>>>>>>> Agents may push branches to forks, but they > >> will > >>>> be > >>>>>>>>> instructed > >>>>>>>>>>> to > >>>>>>>>>>>>> avoid > >>>>>>>>>>>>>>>>> creating PRs on their own to the upstream > >>>> repository, > >>>>>> and > >>>>>>>>>>> instead > >>>>>>>>>>>>>>> provide > >>>>>>>>>>>>>>>>> the link for creating the PR using this > >> template > >>>> (they > >>>>>>>> could > >>>>>>>>>>>>> suggest an > >>>>>>>>>>>>>>> AI > >>>>>>>>>>>>>>>>> summary, but the contributor should copy and > >>>> paste it > >>>>>>>>> manually > >>>>>>>>>>> to > >>>>>>>>>>>>> the > >>>>>>>>>>>>>>>>> collapsible box). Trying to work around that > >>> might > >>>>>> result > >>>>>>>>> in an > >>>>>>>>>>> M&M > >>>>>>>>>>>>> test > >>>>>>>>>>>>>>>>> directly in the PR's description (TBD). > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Example is available here < > >>>>>>>>>>>>> https://github.com/apache/airflow/pull/68055> > >>>>>>>>>>>>>>> - > >>>>>>>>>>>>>>>>> I've made HTML comments visible, they will be > >>>> hidden > >>>>>> in > >>>>>>>> the > >>>>>>>>> real > >>>>>>>>>>>>> thing. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Took inspiration for this idea from > >>>>>>>>> https://tenbluelinks.org/ , > >>>>>>>>>>>>> that > >>>>>>>>>>>>>>> hides > >>>>>>>>>>>>>>>>> the AI overview on Google if you're not > >>> interested > >>>>>>>>>>>>> (highly-recommended > >>>>>>>>>>>>>>>>> btw). > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Can we live with that? > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Shahar > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> On Tue, Jun 9, 2026 at 3:30 PM Ash > >>> Berlin-Taylor < > >>>>>>>>>>> [email protected]<mailto:[email protected]>> > >>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I don’t care one way or another about using > >> AI > >>>> as a > >>>>>> tool > >>>>>>>>> in CI, > >>>>>>>>>>>>> that is > >>>>>>>>>>>>>>>>>> secondary to my goal which is to try and do > >>>>>> something to > >>>>>>>>> make > >>>>>>>>>>> it > >>>>>>>>>>>>> clear > >>>>>>>>>>>>>>>>> what > >>>>>>>>>>>>>>>>>> we expect from people wanting to contribute > >> to > >>>>>> Airflow, > >>>>>>>>> namely: > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> 1. Human involvement. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> By submitting a PR you are saying “yes I want > >>> to > >>>> be a > >>>>>>>>> member > >>>>>>>>>>> of the > >>>>>>>>>>>>>>>>>> community”. Agents submitting without human > >>>>>> interaction > >>>>>>>> go > >>>>>>>>>>> against > >>>>>>>>>>>>>>> this. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> 2. Human ownership. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> It is _your responsibility_ as the PR author > >> to > >>>>>> follow up > >>>>>>>>> on > >>>>>>>>>>> it, > >>>>>>>>>>>>>>> address > >>>>>>>>>>>>>>>>>> comments, and request reviews. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I frankly find the AI generated triage > >> comments > >>>>>> verbose, > >>>>>>>>> and a > >>>>>>>>>>>>> waste > >>>>>>>>>>>>>>> of > >>>>>>>>>>>>>>>>>> time and pure noise even without the `@` > >> spam. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> If the user doesn’t care enough about their > >> own > >>>> PR to > >>>>>>>>> follow > >>>>>>>>>>> up on > >>>>>>>>>>>>> it: > >>>>>>>>>>>>>>>>>> close it after some time. We don’t need to > >> baby > >>>> sit > >>>>>> them. > >>>>>>>>> Nor > >>>>>>>>>>> do I > >>>>>>>>>>>>> need > >>>>>>>>>>>>>>>>> yet > >>>>>>>>>>>>>>>>>> more commit email messages to read through. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> So how does it sound: It sounds like hell to > >> me > >>>> and > >>>>>> an > >>>>>>>> even > >>>>>>>>>>> bigger > >>>>>>>>>>>>>>> waste > >>>>>>>>>>>>>>>>>> of electricity in a climate crisis. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> I want to be involved in a community of > >> humans > >>>>>> working to > >>>>>>>>> build > >>>>>>>>>>>>>>> software. > >>>>>>>>>>>>>>>>>> I do not want to see LLMs producing so much > >>>> output > >>>>>> that > >>>>>>>>> other > >>>>>>>>>>>>> people > >>>>>>>>>>>>>>> need > >>>>>>>>>>>>>>>>>> LLMs to summarise it, with no humans looking > >> at > >>>>>> things. > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> -ash > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On 9 Jun 2026, at 13:18, Jarek Potiuk < > >>>>>> [email protected] > >>>>>>>>> <mailto:[email protected]>> > >>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Why? Because AI “instructions” cannot be > >>>> trusted. > >>>>>> And I > >>>>>>>>> am > >>>>>>>>>>> after > >>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>>> signal > >>>>>>>>>>>>>>>>>>> that people are blindly using LLMs without > >>>> enough > >>>>>> human > >>>>>>>>>>>>> introversion. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> But is not that what you are doing? This > >>>> proposal is > >>>>>>>> about > >>>>>>>>>>> adding > >>>>>>>>>>>>>>>>> another > >>>>>>>>>>>>>>>>>>> AI instruction (just hidden in HTML) - how > >> is > >>>> that > >>>>>> going > >>>>>>>>> to > >>>>>>>>>>> help? > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> You already updated the instructions to not > >>>> `@` the > >>>>>>>>> reviewer > >>>>>>>>>>> here > >>>>>>>>>>>>>>>>>>> Indeed, LLMs are not deterministic by > >> nature. > >>>> But > >>>>>> they > >>>>>>>> are > >>>>>>>>>>>>> improvable. > >>>>>>>>>>>>>>>>>>> Through iterations of refinement and adding > >>> more > >>>>>>>>> guardrails > >>>>>>>>>>> we can > >>>>>>>>>>>>>>>>>> improve > >>>>>>>>>>>>>>>>>>> it—and this is exactly why I am running it > >>>> manually > >>>>>> to > >>>>>>>>> make it > >>>>>>>>>>>>> better. > >>>>>>>>>>>>>>>>>> This > >>>>>>>>>>>>>>>>>>> is the same as in regular breeze development > >>> in > >>>> the > >>>>>>>> past. > >>>>>>>>>>>>> Initially, > >>>>>>>>>>>>>>>>>> there > >>>>>>>>>>>>>>>>>>> were many small issues - and I remember how > >>> you > >>>>>>>> complained > >>>>>>>>>>> about > >>>>>>>>>>>>> them > >>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>> how unnecessary they seemed—yet we now > >>>> perfected it > >>>>>> over > >>>>>>>>> time. > >>>>>>>>>>>>> Now, it > >>>>>>>>>>>>>>>>>>> allows all contributors and maintainers to > >>> work > >>>> much > >>>>>>>> more > >>>>>>>>>>>>> efficiently > >>>>>>>>>>>>>>>>> and > >>>>>>>>>>>>>>>>>>> lose less time. BTW. Thanks for notifying > >> me; > >>> I > >>>> must > >>>>>>>>>>> strengthen > >>>>>>>>>>>>> this > >>>>>>>>>>>>>>>>> one > >>>>>>>>>>>>>>>>>>> and see why, as there might be another > >>>> improvement > >>>>>> to > >>>>>>>>>>> implement. > >>>>>>>>>>>>> This > >>>>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>> also why we are not "yet" doing CI analysis > >> by > >>>> AI - > >>>>>>>>> because I > >>>>>>>>>>>>> want to > >>>>>>>>>>>>>>>>>>> iterate on it and fix it in the way to know > >>>> which > >>>>>> parts > >>>>>>>>> are > >>>>>>>>>>>>>>>>>> deterministic. > >>>>>>>>>>>>>>>>>>>> I want to do anything and everything to > >>> reduce > >>>> the > >>>>>>>> drive > >>>>>>>>> by > >>>>>>>>>>>>>>>>> contribution > >>>>>>>>>>>>>>>>>>> with no human activity. I’m happy to spend > >> my > >>>> time > >>>>>>>> helping > >>>>>>>>>>>>> humans, but > >>>>>>>>>>>>>>>>> if > >>>>>>>>>>>>>>>>>>> they are just going to feed that back to an > >>> LLM > >>>> and > >>>>>> burn > >>>>>>>>> an > >>>>>>>>>>>>> egregious > >>>>>>>>>>>>>>>>>>> amount of carbon: no thank you. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> And again I am not sure how the proposal to > >>> add > >>>> that > >>>>>>>>>>> instruction > >>>>>>>>>>>>> would > >>>>>>>>>>>>>>>>>>> address this particular issue? Are you just > >>>>>> proposing to > >>>>>>>>> add > >>>>>>>>>>>>> another > >>>>>>>>>>>>>>>>>>> instruction for the LLM (or am I wrong?). > >> How > >>>> does > >>>>>> it > >>>>>>>>> solve > >>>>>>>>>>> the > >>>>>>>>>>>>>>>>> problem? > >>>>>>>>>>>>>>>>>>> From what I understand we have two basic > >>>> proposals > >>>>>>>> here - > >>>>>>>>>>> that > >>>>>>>>>>>>>>>>> contradict > >>>>>>>>>>>>>>>>>>> each other: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> * Ash - do not use AI to fight with AI at > >> all > >>>>>>>>>>>>>>>>>>> * Amoght, Shahar - use AI in CI > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> But I think, the triage I am running now > >>> shows a > >>>>>> third > >>>>>>>>> way: > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> * we use AI to try out and generate triage > >>>> action > >>>>>> and > >>>>>>>>> figure > >>>>>>>>>>> out > >>>>>>>>>>>>> which > >>>>>>>>>>>>>>>>>>> parts are practically 100% deterministic and > >>> can > >>>>>> help > >>>>>>>> with > >>>>>>>>>>> triage > >>>>>>>>>>>>>>> (this > >>>>>>>>>>>>>>>>>> is > >>>>>>>>>>>>>>>>>>> the stats I am gathering now) > >>>>>>>>>>>>>>>>>>> * qe use AI to convert the SKILLS we have > >> into > >>>>>>>>> deterministic > >>>>>>>>>>> CI > >>>>>>>>>>>>> code > >>>>>>>>>>>>>>>>> that > >>>>>>>>>>>>>>>>>>> does those triage steps (no AI used at all > >> at > >>>>>> runtime) > >>>>>>>>>>>>>>>>>>> * we continue perfecting the > >>> manually-triggered > >>>> AI > >>>>>>>> SKILLS > >>>>>>>>> to > >>>>>>>>>>> get > >>>>>>>>>>>>> more > >>>>>>>>>>>>>>>>> AI > >>>>>>>>>>>>>>>>>>> heuristics that we can turn into > >> deterministic > >>>> CI > >>>>>> code > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> This seems to fulfill seemingly > >> contradictory > >>>>>>>> expectations > >>>>>>>>>>> that > >>>>>>>>>>>>>>>>> different > >>>>>>>>>>>>>>>>>>> people have in a nice way. I am about to > >>> produce > >>>>>> stats > >>>>>>>>> from > >>>>>>>>>>> the > >>>>>>>>>>>>> last > >>>>>>>>>>>>>>>>> run > >>>>>>>>>>>>>>>>>>> and was just about to propose this approach. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> How does it sound Ash, Amogh, Shahar and > >>> others > >>>> ? > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> J. > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>> On Tue, Jun 9, 2026 at 12:55 PM Ash > >>>> Berlin-Taylor < > >>>>>>>>>>> [email protected]<mailto:[email protected]> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>> Why? Because AI “instructions” cannot be > >>>> trusted. > >>>>>> And I > >>>>>>>>> am > >>>>>>>>>>> after > >>>>>>>>>>>>> a > >>>>>>>>>>>>>>>>>> signal > >>>>>>>>>>>>>>>>>>>> that people are blindly using LLMs without > >>>> enough > >>>>>> human > >>>>>>>>>>>>> introversion. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> Want a prime example? > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> The pr triage skill. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> You already updated the instructions to not > >>>> `@` the > >>>>>>>>> reviewer > >>>>>>>>>>> here > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>> > >>>> > >>> > >> > https://github.com/apache/airflow-steward/blob/76cfa5e1d2e682b88df5205e9cda396df51a66b6/skills/pr-management-triage/comment-templates.md#reviewer-mention-policy > >>>>>>>>>>>>>>>>>>>>> When a comment's only addressee is the PR > >>>> author > >>>>>> (the > >>>>>>>>>>>>>>>>>>>> request-author-confirmation, reviewer-ping > >>>>>>>>> author-primary, > >>>>>>>>>>> and > >>>>>>>>>>>>>>>>>> review-nudge > >>>>>>>>>>>>>>>>>>>> author-primary templates), the body > >>> references > >>>> the > >>>>>>>>> reviewer > >>>>>>>>>>>>> without > >>>>>>>>>>>>>>>>>>>> @-mentioning them > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> And yet the LLM did it again: > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> > >>>> https://github.com/apache/airflow/pull/66633#discussion_r3344849352 > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> @korex-f — A reviewer (@ashb) has > >> requested > >>>>>> changes on > >>>>>>>>> this > >>>>>>>>>>> PR, > >>>>>>>>>>>>> so > >>>>>>>>>>>>>>>>> I've > >>>>>>>>>>>>>>>>>>>> removed the ready for maintainer review > >> label > >>>> — the > >>>>>>>> next > >>>>>>>>>>> step is > >>>>>>>>>>>>> on > >>>>>>>>>>>>>>>>> your > >>>>>>>>>>>>>>>>>>>> side. Could you address the review comments > >>>> (push a > >>>>>>>> fix, > >>>>>>>>> or > >>>>>>>>>>> reply > >>>>>>>>>>>>>>>>>> in-thread > >>>>>>>>>>>>>>>>>>>> explaining why the feedback doesn't apply)? > >>>> Once > >>>>>>>>> addressed, > >>>>>>>>>>>>>>> re-request > >>>>>>>>>>>>>>>>>>>> review from @ashb or re-mark the PR ready > >> and > >>>> it > >>>>>>>> returns > >>>>>>>>> to > >>>>>>>>>>> the > >>>>>>>>>>>>>>>>>> maintainer > >>>>>>>>>>>>>>>>>>>> queue. Thank you. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> And frankly I’m tired of all this shit. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> I want to do anything and everything to > >>> reduce > >>>> the > >>>>>>>> drive > >>>>>>>>> by > >>>>>>>>>>>>>>>>> contribution > >>>>>>>>>>>>>>>>>>>> with no human activity. I’m happy to spend > >> my > >>>> time > >>>>>>>>> helping > >>>>>>>>>>>>> humans, > >>>>>>>>>>>>>>> but > >>>>>>>>>>>>>>>>>> if > >>>>>>>>>>>>>>>>>>>> they are just going to feed that back to an > >>>> LLM and > >>>>>>>> burn > >>>>>>>>> an > >>>>>>>>>>>>> egregious > >>>>>>>>>>>>>>>>>>>> amount of carbon: no thank you. > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> -ash > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> On 9 Jun 2026, at 10:38, Jarek Potiuk < > >>>>>>>> [email protected] > >>>>>>>>> <mailto:[email protected]>> > >>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Hi Ash, Amogh, and Shahar, > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Ash, I'm curious to learn more about how > >> the > >>>>>> "brown > >>>>>>>> m&m > >>>>>>>>>>> test" > >>>>>>>>>>>>>>> differs > >>>>>>>>>>>>>>>>>>>> from > >>>>>>>>>>>>>>>>>>>>> our current request for agents to identify > >>>>>> themselves. > >>>>>>>>>>> Could you > >>>>>>>>>>>>>>> help > >>>>>>>>>>>>>>>>>> me > >>>>>>>>>>>>>>>>>>>>> understand the flow and the specific > >>> benefits > >>>> you > >>>>>> see? > >>>>>>>>> It > >>>>>>>>>>> feels > >>>>>>>>>>>>>>>>> similar > >>>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>> me, but I'd love to hear your perspective > >> in > >>>> case > >>>>>> I'm > >>>>>>>>>>> missing a > >>>>>>>>>>>>>>>>> nuance. > >>>>>>>>>>>>>>>>>>>>> Regarding the gh pr create --web approach, > >>> we > >>>>>> included > >>>>>>>>> those > >>>>>>>>>>>>>>>>>> instructions > >>>>>>>>>>>>>>>>>>>>> to ensure we meet ASF legal guidelines for > >>>> Gen-AI > >>>>>>>>> headers, > >>>>>>>>>>> and > >>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>> support > >>>>>>>>>>>>>>>>>>>>> contributors who might not have Copilot. > >>> That > >>>>>> said, if > >>>>>>>>> you > >>>>>>>>>>> have > >>>>>>>>>>>>>>> ideas > >>>>>>>>>>>>>>>>>> on > >>>>>>>>>>>>>>>>>>>>> how to trim the context or improve the > >>>> templates, > >>>>>> we > >>>>>>>>> truly > >>>>>>>>>>>>>>> appreciate > >>>>>>>>>>>>>>>>>> PRs > >>>>>>>>>>>>>>>>>>>>> that improve them—and many people already > >>>> have. > >>>>>>>>> AGENTS.md > >>>>>>>>>>> is a > >>>>>>>>>>>>> team > >>>>>>>>>>>>>>>>>>>> effort, > >>>>>>>>>>>>>>>>>>>>> and we’re always looking for ways to make > >> it > >>>>>> better. > >>>>>>>>> Let's > >>>>>>>>>>> keep > >>>>>>>>>>>>> our > >>>>>>>>>>>>>>>>>>>>> collaboration positive as we refine these > >>>>>> processes > >>>>>>>>>>> together. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Amogh and Shahar, yep the idea of an > >>> validatio > >>>>>> step in > >>>>>>>>> the > >>>>>>>>>>> CI > >>>>>>>>>>>>> for > >>>>>>>>>>>>>>>>>>>>> first-time contributions is something we > >>>> should > >>>>>>>>> implement > >>>>>>>>>>>>> sooner or > >>>>>>>>>>>>>>>>>>>> later. > >>>>>>>>>>>>>>>>>>>>> I have actually been gathering stats on > >> this > >>>> for > >>>>>> the > >>>>>>>>> last > >>>>>>>>>>> two > >>>>>>>>>>>>> weeks. > >>>>>>>>>>>>>>>>>> I’ve > >>>>>>>>>>>>>>>>>>>>> been preparing to see how manually > >> triggered > >>>>>> triage > >>>>>>>>> tasks > >>>>>>>>>>> can > >>>>>>>>>>>>> turn > >>>>>>>>>>>>>>>>> into > >>>>>>>>>>>>>>>>>>>>> automated ones—I'm gathering stats on when > >>>> human > >>>>>>>>> judgment is > >>>>>>>>>>>>> needed. > >>>>>>>>>>>>>>>>> I > >>>>>>>>>>>>>>>>>>>>> shared some stats about this recently and > >>> will > >>>>>>>> continue > >>>>>>>>>>>>> gathering > >>>>>>>>>>>>>>>>> them. > >>>>>>>>>>>>>>>>>>>> The > >>>>>>>>>>>>>>>>>>>>> next step is discussing here what and how > >> we > >>>> can > >>>>>>>>> automate. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Also, the current triage process already > >>> uses > >>>> our > >>>>>> Pull > >>>>>>>>>>> Request > >>>>>>>>>>>>>>>>> criteria > >>>>>>>>>>>>>>>>>>>> to > >>>>>>>>>>>>>>>>>>>>> pre-classify the PRs and only marks them > >>> with > >>>>>> "ready > >>>>>>>> for > >>>>>>>>>>>>> maintainer > >>>>>>>>>>>>>>>>>>>> review" > >>>>>>>>>>>>>>>>>>>>> if those criteria are met. So, if there > >> are > >>>> any > >>>>>>>> specific > >>>>>>>>>>>>> criteria > >>>>>>>>>>>>>>>>> you’d > >>>>>>>>>>>>>>>>>>>>> like to see added to our "Pull request > >>>> criteria," > >>>>>> PRs > >>>>>>>>> are > >>>>>>>>>>> most > >>>>>>>>>>>>>>>>> welcome > >>>>>>>>>>>>>>>>>>>>> there as well. > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>>>>> Jarek > >>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> > >>>> --------------------------------------------------------------------- > >>>>>>>>>>>>>>>>>> To unsubscribe, e-mail: > >>>>>>>> [email protected] > >>>>>>>>> <mailto:[email protected]> > >>>>>>>>>>>>>>>>>> For additional commands, e-mail: > >>>>>>>>> [email protected]<mailto: > >> [email protected] > >>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>> > >> --------------------------------------------------------------------- > >>>>>>>>>>>>>>> To unsubscribe, e-mail: > >>>>>> [email protected] > >>>>>>>>> <mailto:[email protected]> > >>>>>>>>>>>>>>> For additional commands, e-mail: > >>>>>> [email protected] > >>>>>>>>> <mailto:[email protected]> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>> > >>>> --------------------------------------------------------------------- > >>>>>>>>>>>>> To unsubscribe, e-mail: > >>>> [email protected] > >>>>>>>> <mailto: > >>>>>>>>> [email protected]> > >>>>>>>>>>>>> For additional commands, e-mail: > >>>> [email protected] > >>>>>>>>> <mailto:[email protected]> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>> > >> --------------------------------------------------------------------- > >>>>>>>>>>> To unsubscribe, e-mail: > >> [email protected] > >>>>>> <mailto: > >>>>>>>>> [email protected]> > >>>>>>>>>>> For additional commands, e-mail: > >>> [email protected] > >>>>>> <mailto: > >>>>>>>>> [email protected]> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>> --------------------------------------------------------------------- > >>>>>>>>> To unsubscribe, e-mail: [email protected] > >>>> <mailto: > >>>>>>>>> [email protected]> > >>>>>>>>> For additional commands, e-mail: [email protected] > >>>> <mailto: > >>>>>>>>> [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] > >>>> > >>>> > >>> > >> > >
