It is a little confusing to keep track of the proposed diffs to Rust's policy. I think David is preparing a version with all the changes applied to it, so there is no ambiguity.
> How would we handle the “Non-critical” part of the experimental section? The > policy exempts rust-lang members from that… does this mean we’d exempt > committers but not non-committers. What’s the Cassandra analog of the > non-critical section? The modified proposal removes that paragraph (about exemptions) altogether, thus treating all C* developers equally and allowing code generation for non-critical parts only for everyone. If you are still confused (which would be understandable - it is confusing), perhaps wait for David's doc, to make sure we are all on the same page wrt what's being proposed first. -- AY > On 28 Sep 2026, at 20:16, Blake Eggleston <[email protected]> wrote: > > This is something I could support as well. > > 2 things: > > Our docs tend to be neglected. While ideally our docs would be 100% human > generated, they’re mostly just not generated at the moment. While not ideal, > I think relaxing the rust LLM policy as it relates to docs would be a net > positive for users, provided they’re human reviewed and edited. > > How would we handle the “Non-critical” part of the experimental section? The > policy exempts rust-lang members from that… does this mean we’d exempt > committers but not non-committers. What’s the Cassandra analog of the > non-critical section? > > On Mon, Sep 28, 2026, at 12:10 PM, Francisco Guerrero wrote: >> I've gone over the the Rust policy. I am in support of the Rust >> version with the tweaks proposed by Caleb. >> >> Best, >> - Francisco >> >> On 2026/09/28 18:45:03 Aleksey Yeshchenko via dev 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]> >> > > <mailto:[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://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]> >> > >> <mailto:[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]> >> > >>> <mailto:[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]> >> > >>> > <mailto:[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]> >> > >>> > > > <mailto:[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. >> > >>> > > >> > >> > >>
