+1 on this suggestion. Restricted: > - Core code changes made by LLM may only be proposed by contributors with > demonstrated expertise > - Must have produced similar patches in size, scope and area > unassisted and with minimal third-party guidance > - Core code changes made by LLM require an additional reviewer
Besides, in light of this perspective, should we produce a list of module maintainers? These maintainers could be PMC members or committers. Jon Haddad <[email protected]> 于2026年9月23日周三 03:03写道： > Agreed, Josh. > > Threatening to blindly -1 patches based on a hunch that someone used an > LLM to work on it isn't productive. It's certainly not a door that should > be opened, because it swings both ways. If people start -1'ing patches > because of bitter feelings instead of technical reasoning, why would anyone > want to contribute? > > I am -1 on the policy suggestion. This project is *struggling* to get > things merged in. The idea that we wouldn't take advantage of LLMs to > write or review code doesn't make any sense to me at all. > > Jon > > > On Tue, Sep 22, 2026 at 11:55 AM Josh McKenzie <[email protected]> > wrote: > >> to focus minds, I will remind everyone that the project rules permit >> unilateral vetoes on contributions, and in the absence of any policy on the >> matter that includes AI generated contributions. >> >> Personal opinion here, but this is a counter-productive way to open a >> collaborative discussion. >> >> Since this is out here on thread, I'll take it upon myself to clarify the >> official policy for anyone that's not aware: >> >> https://cwiki.apache.org/confluence/spaces/CASSANDRA/pages/158863606/Cassandra+Project+Governance >> >> >> - Code must not be committed while subject to an explicit -1 vote by >> a committer for clearly expressed and reasonable technical grounds >> - If code has been committed but not released, a -1 vote from a >> committer (that is not resolved by follow-up commits) can be reverted >> - If the proposer responds to the concerns of a -1 voter, and the -1 >> voter does not engage reasonably with the response, the -1 is rescinded >> - Committers should explicitly veto work *exceptionally rarely* >> >> >> I read this as more nuanced than "project rules permit unilateral vetoes >> on contributions". >> >> On Tue, Sep 22, 2026, at 6:27 AM, Benedict wrote: >> >> Hi everyone. Let me preface this by saying that we need a policy on this, >> and we will probably struggle to reach a consensus. So to focus minds, I >> will remind everyone that the project rules permit unilateral vetoes on >> contributions, and in the absence of any policy on the matter that includes >> AI generated contributions. >> >> My proposal in brief is that LLM usage is >> >> ===== >> Encouraged: >> - Reviewing and otherwise validating human-authored patches before >> submission >> - Debugging, diagnosing etc >> >> Permitted: >> - Generating or modifying tests, scripts, tooling or any other non-user >> facing changes >> - Minor changes to human-authored patches that are carefully reviewed by >> the author >> >> Restricted: >> - Core code changes made by LLM may only be proposed by contributors with >> demonstrated expertise >> - Must have produced similar patches in size, scope and area >> unassisted and with minimal third-party guidance >> - Core code changes made by LLM require an additional reviewer >> - LLM review is not a substitute for human review, and must be used only >> to augment a complete and independent human understanding of the patch. >> >> Prohibited: >> - All public prose must be human authored. This includes inline comments, >> docs, posts to Jira etc. >> >> All LLM generated changes MUST be disclosed: >> - Outlined to any reviewer; >> - Summarised in the commit message; >> - Large blocks or files must be individually marked with some agreed >> message like "created by <some AI>" >> ===== >> >> I will keep my argumentation brief. >> >> LLM generated changes: >> - Break the community and knowledge-building aspect of patch review, >> since the contributor is not clearly learning from the feedback process >> - Flips the asymmetry between author and reviewer/maintainer: it is >> now cheaper to write than review or maintain >> - Does not demonstrate expertise, commitment or that they can or will >> maintain the patch >> >> 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 >> >> Authoring a patch results in deeper understanding. To offset the reduced >> collective knowledge of LLM generated changes, and improve our ability to >> confidently maintain it, we should expect changes to be more widely >> socialised through an additional review. >> >> Finally, LLM comments are worse than no comment. An author must ensure >> their reader's time is valued, by investing their own time crafting a >> message with a proper understanding of its intended audience. LLMs may >> assist in preparation, but must not produce the content itself. >> >> I don't believe this fully accounts for all of the risks posed by AI >> usage in the project, especially regarding maintainability of the codebase >> and maintaining the community. But I hope this middle-ground policy will >> prove to be acceptable to enough of the community. >> >> >>
