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