I'm a +1 for the same reason that Josh lays out. Markdown files that detail the structure of the repo, how to build & run tests, how to get checkstyle to pass, etc. are all very valuable to new contributors even if LLMs went away today.
On Tue, Feb 17, 2026 at 7:33 PM Jon Haddad <[email protected]> wrote: > It's all part of the same topic, Yifan. You're making a distinction > without a difference. We could just as easily be discussing supporting > certain MCP servers like serena, or baking claude into a devcontainer. > It's all relevant. There's no need to police the discussion. > > On Tue, Feb 17, 2026 at 4:25 PM Yifan Cai <[email protected]> wrote: > >> The original post was about adding AI tooling, prompt, command, or >> skill. The thread is shifted to AI memory files. >> >> I do not have an objection to any of these, but want to make sure that we >> are still on the original topic. >> >> IMO, AI tooling has a clear scope / definition and is easier to reach >> consensus on. Meanwhile, AI memory files are vague to define clearly. >> Different developers on different domains could have quite different >> preferences. >> >> - Yifan >> >> On Tue, Feb 17, 2026 at 3:37 PM Dmitry Konstantinov <[email protected]> >> wrote: >> >>> I do not have my one but here there are few examples from oher Apache >>> projects: >>> https://github.com/apache/camel/blob/main/AGENTS.md >>> https://github.com/apache/ignite-3/blob/main/CLAUDE.md >>> >>> https://github.com/apache/superset/blob/master/superset/mcp_service/CLAUDE.md >>> >>> >>> On Tue, 17 Feb 2026 at 23:22, Jon Haddad <[email protected]> >>> wrote: >>> >>>> I think a few folks are already using CLAUDE.md files in their repo and >>>> they're just not committing them. >>>> >>>> Anyone want to share what's already done? I'm happy to help share what >>>> I know about the agentic side of things, but since I don't do much in the >>>> way of patching C* it would be a lot of guessing. >>>> >>>> If I'm wrong and nobody shares one, I'll take a stab at it. >>>> >>>> >>>> >>>> On Tue, Feb 17, 2026 at 3:08 PM Štefan Miklošovič < >>>> [email protected]> wrote: >>>> >>>>> Great feedback everybody! Really appreciate it! >>>>> >>>>> Reading what Jon posted ... Jon, I think you are the most experienced >>>>> in this based on what you wrote. Would you mind doing some POC here >>>>> for Cassandra repo? For the trunk it is enough ... Something we might >>>>> build further on. I think we need to build the foundations of that and >>>>> put some structure into it and all things considered I think you are >>>>> best for the job here. >>>>> >>>>> If the basics are there we can play with it more before merging, this >>>>> is not something which needs to be done "tomorrow", we can collaborate >>>>> on something together for some time and add things into it as patches >>>>> come. I think it takes some time to "tune" it. >>>>> >>>>> Everybody else feel free to help! My experience in this space is >>>>> limited, I think there are people who are using it more often than me >>>>> for sure. >>>>> >>>>> Regards >>>>> >>>>> On Wed, Feb 18, 2026 at 12:59 AM Joel Shepherd <[email protected]> >>>>> wrote: >>>>> > >>>>> > There's been some momentum building for AGENTS.md files, both on the >>>>> > project and on the agent side: >>>>> > >>>>> > https://agents.md/ >>>>> > >>>>> > Same idea and benefits, but it might help to align folks on a >>>>> "standard" >>>>> > that will work well across agents. >>>>> > >>>>> > I also think that more and better code documentation can be very >>>>> > beneficial when using agents to help with working out implementation >>>>> > details. I spent a bunch of time in January writing an introduction >>>>> to >>>>> > Apache Ratis (Raft as a library: >>>>> > >>>>> https://github.com/apache/ratis/blob/master/ratis-docs/src/site/markdown/index.md >>>>> ). >>>>> > The code itself is pretty well-documented but it was hard for me to >>>>> > build a mental model of how to integrate with. AI was very effective >>>>> in >>>>> > taking the granular in-code documentation and synthesizing an >>>>> overview >>>>> > from it. Going the other way, the in-code documentation has made it >>>>> > possible for me to deep dive the Ratis code to root cause bugs, etc. >>>>> > Agents can get a lot out of good class- and method-level >>>>> documentation. >>>>> > >>>>> > -- Joel. >>>>> > >>>>> > On 2/16/2026 8:03 PM, Bernardo Botella wrote: >>>>> > > CAUTION: This email originated from outside of the organization. >>>>> Do not click links or open attachments unless you can confirm the sender >>>>> and know the content is safe. >>>>> > > >>>>> > > >>>>> > > >>>>> > > Thanks for bringing this up Stefan!! >>>>> > > >>>>> > > A really interesting topic indeed. >>>>> > > >>>>> > > >>>>> > > I’ve also heard ideas around even having Claude.md type of files >>>>> that help LLMs understand the code base without having to do a full scan >>>>> every time. >>>>> > > >>>>> > > So, all and all, putting together something that we as a community >>>>> think that describe good practices + repository information not only for >>>>> the main Cassandra repository, but also for its subprojects, will >>>>> definitely help contributors adhere to standards and us reviewers to >>>>> ensure >>>>> that some steps at least will have been considered. >>>>> > > >>>>> > > Things like: >>>>> > > - Repository structure. What every folder is >>>>> > > - Tests suits and how they work and run >>>>> > > - Git commits standards >>>>> > > - Specific project lint rules (like braces in new lines!) >>>>> > > - Preferred wording style for patches/documentation >>>>> > > >>>>> > > Committed to the projects, and accesible to LLMs, sound like >>>>> really useful context for those type of contributions (that are going to >>>>> keep happening regardless). >>>>> > > >>>>> > > So curious to read what others think. >>>>> > > Bernardo >>>>> > > >>>>> > > PD. Totally agree that this should change nothing of the quality >>>>> bar for code reviews and merged code >>>>> > > >>>>> > >> On Feb 16, 2026, at 6:27 PM, Štefan Miklošovič < >>>>> [email protected]> wrote: >>>>> > >> >>>>> > >> Hey, >>>>> > >> >>>>> > >> This happened recently in kernel space. (1), (2). >>>>> > >> >>>>> > >> What that is doing, as I understand it, is that you can point LLM >>>>> to >>>>> > >> these resources and then it would be more capable when reviewing >>>>> > >> patches or even writing them. It is kind of a guide / context >>>>> provided >>>>> > >> to AI prompt. >>>>> > >> >>>>> > >> I can imagine we would just compile something similar, merge it >>>>> to the >>>>> > >> repo, then if somebody is prompting it then they would have an >>>>> easier >>>>> > >> job etc etc, less error prone ... adhered to code style etc ... >>>>> > >> >>>>> > >> This might look like a controversial topic but I think we need to >>>>> > >> discuss this. The usage of AI is just more and more frequent. From >>>>> > >> Cassandra's perspective there is just this (3) but I do not think >>>>> we >>>>> > >> reached any conclusions there (please correct me if I am wrong >>>>> where >>>>> > >> we are at with AI generated patches). >>>>> > >> >>>>> > >> This is becoming an elephant in the room, I am noticing that some >>>>> > >> patches for Cassandra were prompted by AI completely. I think it >>>>> would >>>>> > >> be way better if we make it easy for everybody contributing like >>>>> that. >>>>> > >> >>>>> > >> This does not mean that we, as committers, would believe what AI >>>>> > >> generated blindlessly. Not at all. It would still need to go over >>>>> the >>>>> > >> formal review as anything else. But acting like this is not >>>>> happening >>>>> > >> and people are just not going to use AI when trying to contribute >>>>> is >>>>> > >> not right. We should embrace it in some form ... >>>>> > >> >>>>> > >> 1) https://github.com/masoncl/review-prompts >>>>> > >> 2) >>>>> https://lore.kernel.org/lkml/[email protected]/ >>>>> > >> 3) >>>>> https://lists.apache.org/thread/j90jn83oz9gy88g08yzv3rgyy0vdqrv7 >>>>> >>>> >>> >>> -- >>> Dmitry Konstantinov >>> >>
