> All public prose must be human authored. This includes inline comments, docs, posts to Jira etc.
I agree with this if by "authored" we mean "authored or closely audited for brevity and correctness". The value of verbose inline documentation in our world is certainly declining, and all but the most necessary comments risk confusing LLM comprehension of the codebase rather than enhancing it. On Tue, Sep 22, 2026 at 9:13 PM guo Maxwell <[email protected]> wrote: > +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. >>> >>> >>>
