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