I would also support a version of the Rust policy tweaked as Caleb proposes.
Thanks, Sam > On 28 Sep 2026, at 19:45, Aleksey Yeshchenko via dev > <[email protected]> wrote: > > Some last minute amends to the suggested policy's TL;DR, with Caleb's > approval: > > - It’s fine to use LLMs to answer questions, analyze, distill, refine, check, > suggest, review. > - LLMs work best when used as a tool to write better, not faster. > > "But not to create." bit is covered in detail by the full policy and is > impossible to summarise well in two words. > > With other changes as outlined by Caleb in the quoted email, I would be happy > to support this fine-tuned version of Rust's policy. > > -- > AY > >> On 28 Sep 2026, at 19:27, Caleb Rackliffe <[email protected] >> <mailto:[email protected]>> wrote: >> >> To clarify, I would remove the "Experimental" tag and make that section >> apply to all contributors. (In other words, encourage attribution, quality, >> and human decision-making for all of us.) >> >> The spirit of this is really a one line change to the Rust policy: >> >> > It’s fine to use LLMs to answer questions, analyze, distill, refine, >> > check, suggest, review. But not to create. >> >> ...becomes... >> >> It’s fine to use LLMs to answer questions, analyze, distill, refine, check, >> suggest, review. But not to decide. >> >> >> >> On Mon, Sep 28, 2026 at 12:54 PM Caleb Rackliffe <[email protected] >> <mailto:[email protected]>> wrote: >>> I finally read the Rust and Lucene policy docs in more detail... >>> >>> https://flagged.apple.com:443/proxy?t2=Dx1j3o8bN8&o=aHR0cHM6Ly9mb3JnZS5ydXN0LWxhbmcub3JnL3BvbGljaWVzL2xsbS11c2FnZS5odG1s&emid=10aadc4f-b52a-4662-9281-ce00061a230c&c=11 >>> >>> <https://flagged.apple.com/proxy?t2=Dx1j3o8bN8&o=aHR0cHM6Ly9mb3JnZS5ydXN0LWxhbmcub3JnL3BvbGljaWVzL2xsbS11c2FnZS5odG1s&emid=10aadc4f-b52a-4662-9281-ce00061a230c&c=11> >>> https://github.com/apache/lucene/blob/main/AI_POLICY.md >>> >>> I think I agree with a lot of what's written in both, and they overlap >>> quite a lot, especially around communication (docs, issue comments, etc.) >>> that should be primarily human-to-human. Everything useful in the Lucene >>> policy is already included in the Rust policy though. If we could take the >>> Rust policy, generalize away the Rust-specific things, simplify it, and >>> remove the "Experimental" tag (and probably the "non-critical" qualifier) >>> on the "LLM-created code changes intended of review" section, I think >>> that's something a large majority of us would be able to live with. >>> >>> If we can get this right, it's simply clarifying the set of things >>> contributors (including existing committers) can do to have the best chance >>> at getting engagement from reviewers. >>> >>> I don't know how much appetite there is out there for a formal draft of >>> this, and we already have 3-4 proposals, but I could attempt it if that >>> would be useful... >>> >>> >>> On Mon, Sep 28, 2026 at 10:50 AM Štefan Miklošovič <[email protected] >>> <mailto:[email protected]>> wrote: >>>> A clarification from my side, I asked "what is wrong with this" in my >>>> latest email: >>>> >>>> "For these reasons, it should be expected that the person producing >>>> the patch has already demonstrated their expertise and commitment by >>>> producing and maintaining similar patches without the use of AI" >>>> >>>> It is "almost fine", the part of "similar patches without the use of >>>> AI" should not be there. It should stop before that. >>>> >>>> Otherwise this is going to exclude people who have a decade of >>>> experience with Cassandra and contributed countless patches of various >>>> size and complexity while according to that exact wording, they would >>>> not be eligible to contribute an AI patch. That is silly. I think this >>>> is wrong. It does not matter how it was produced. What is important is >>>> established trust and if a patch is correct. What does even the size >>>> of a patch have in common with that? Expertise and commitment! Not >>>> "the series of patches this committer ever produced was not complex >>>> enough so we can't take that code in". >>>> >>>> Also, who is exactly going to measure that anyway? What are the >>>> _objective_ criteria who qualifies? Somebody might come and say "while >>>> based on my criteria, (because I do not like this person), I do not >>>> think that the patches of this person qualify, because ...". We need >>>> hard data on whether it can be merged or not, performance improvement, >>>> stability ... >>>> >>>> I think this particular wording would need to be refined further. >>>> >>>> On Mon, Sep 28, 2026 at 4:34 PM Štefan Miklošovič >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> > >>>> > Right ... for that reason I don't think we should restrict anybody to >>>> > create a PR or anything like that, putting some artificial constraints >>>> > people will eventually bypass anyway. We don't have that under >>>> > control. What we have under control is the review part of that. A >>>> > patch not merged will not be released. The review itself is the >>>> > "gate". >>>> > >>>> > If a PR, even done by AI, is up to standards, has everything it should >>>> > have and it is technically correct, then I can not reject to merge >>>> > that only on the basis it was AI-generated. A patch like a patch. The >>>> > code speaks. The ultimate gate is if a patch is correct or not, not >>>> > how it was produced. >>>> > >>>> > Do I gravitate with my trust more towards established members of the >>>> > community? Definitely. The trust is earned over the years. Implicitly, >>>> > I am trusting a newcomer less. Sorry but not sorry. If somebody calls >>>> > this "gating", I don't think they see the nuances enough. Yeah, call >>>> > it a gate if you want ... >>>> > >>>> > That is why I agree with Benedict here, he said: >>>> > >>>> > "For these reasons, it should be expected that the person producing >>>> > the patch has already demonstrated their expertise and commitment by >>>> > producing and maintaining similar patches without the use of AI". >>>> > >>>> > What is wrong about this? >>>> > >>>> > Look at this contributor (1). This is an excellent example. 10 patches >>>> > in fast cadence three weeks ago. We never heard about this person >>>> > before nor after the patches were created. What about hitting a ML >>>> > saying "hey, guys, I have a set of patches which scratch my itches, >>>> > can you take a look, please?". I don't know ... just be a bit ... >>>> > human about all of this? The maintainers are people too. I am not >>>> > obliged to take in and cooperate with whoever comes by, dumps their >>>> > stuff and then they ... wait. Well, so wait. See where you got three >>>> > weeks after? Nowhere. >>>> > >>>> > Caleb put it nicely, we are "only" humans. >>>> > >>>> > (1) >>>> > https://github.com/apache/cassandra/pulls?q=is%3Apr+state%3Aopen+author%3Acheeeee >>>> > >>>> > On Mon, Sep 28, 2026 at 2:51 PM Shailaja Koppu via dev >>>> > <[email protected] <mailto:[email protected]>> wrote: >>>> > > >>>> > > Hi Stefan, >>>> > > >>>> > > From personal side, I completely agree with you. I am giving potential >>>> > > options only to address concerns like - new contributors overwhelming >>>> > > the community with AI generated PRs just to show as add-on in their >>>> > > profile and vanish after that, or purely AI opened PRs without >>>> > > developer review or understanding. But the later can happen with >>>> > > anyone including committers due to workload/deadlines or misled by AI >>>> > > etc. Also, someone can copy a AI generated patch line by line skipping >>>> > > comments, which looks like a handwritten code. >>>> > > >>>> > > >>>> > > Thanks, >>>> > > Shailaja >>>> > > >>>> > > >>>> > > >>>> > > > On Sep 28, 2026, at 12:23 PM, Štefan Miklošovič >>>> > > > <[email protected] <mailto:[email protected]>> wrote: >>>> > > > >>>> > > >> - Only Cassandra committers may submit AI-assisted PRs. This would >>>> > > >> mean new contributors first write and understand code without AI >>>> > > >> before becoming committers; or >>>> > > >> - Contributors may submit AI-assisted changes in a >>>> > > >> component/subcomponent only after they have submitted at least one >>>> > > >> non-AI PR in that component/subcomponent. >>>> > > > >>>> > > > I am not sure if I am missing something but can you all explain in >>>> > > > simple terms how is this actually enforceable in practice? >>>> > > > >>>> > > > "Only Cassandra committers may submit AI-assisted PRs" - there is no >>>> > > > restriction who can create a PR and how. It is not like we see that a >>>> > > > PR is created with heavy AI usage, then we check if a contributor is >>>> > > > a >>>> > > > committer and when they are not we comment on that PR saying - "hold >>>> > > > your horses mate, we checked the list and you are not a committer, >>>> > > > sorry, we have to close this". >>>> > > > >>>> > > > If a PR is crafted "carefuly" then it might look like a completely >>>> > > > legitimate piece of work while it is still 100% prompted and the >>>> > > > author does not have a clue what they did. I mean ... how do you make >>>> > > > the difference between what is "real" and what is AI-driven 100%? I >>>> > > > think that even if we "guessed" which one is which, the possibility >>>> > > > to >>>> > > > see this is being progressively erased as this tech is evolving and >>>> > > > we >>>> > > > will eventually not have a clue. >>>> > >
