To expand on that, it feels like the questions are around how prescriptive we are going to be and how much support we'll provide? (ex. Do we provide a project CLAUDE.md that influences things like JavaDoc brevity?)
On Tue, Sep 22, 2026 at 10:27 PM Caleb Rackliffe <[email protected]> wrote: > > 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. >>>> >>>> >>>>
