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