> If we do a big bang then it will be way more difficult to retrofit their > patches (or they will become flat out obsolete / irrelevant if the content > changes). Content changing not much we could do about that; overlapping work is overlapping work.
For the difficulty retrofitting - modern LLM's should be more than capable of taking a relatively stale patch and rejiggering it to fit with a changed codebase when it comes to doc structure. On Fri, Apr 10, 2026, at 11:14 AM, Patrick McFadin wrote: > You raise a really good point, and I agree, clearing out this backlog first > could be the right idea. I can start going through them and approving or > commenting. This is a huge backlog, but I don't want to leave them out there. > > On Fri, Apr 10, 2026 at 12:12 AM Štefan Miklošovič <[email protected]> > wrote: >> Big bang or not, there are existing PRs targeting some fixes for docs >> (1). I happen to label these PRs like that and just move on. I was >> planning to take a holistic look at all of them closer to the release >> of 6.0 we are and do it in one merge and be done with it. I prefer to >> just accumulate the PRs over time and do it all in bulk. >> >> I would appreciate it a lot if we deal with these PRs somehow at this >> point. I think the authors of these PRs deserve their patches to be >> looked at, out of respect for their time and effort. If we do a big >> bang then it will be way more difficult to retrofit their patches (or >> they will become flat out obsolete / irrelevant if the content >> changes). I think it would be better if we do the refactorisation with >> their fixes already in so we do not miss them. >> >> (1) >> https://github.com/apache/cassandra/pulls?q=is%3Aopen+is%3Apr+label%3Adocs >> >> On Thu, Apr 9, 2026 at 5:52 PM David Capwell <[email protected]> wrote: >> > >> > > For the purpose of producing my own documentation to use as a user, I >> > > took the antlr grammar for Accord CQL and used a model to generate a few >> > > dozen examples of what's possible and not possible in the syntax. I'd >> > > love for something like this to be included in the Accord section. >> > >> > >> > PR open from before I went on leave. Believe all feedback has been >> > addressed just waiting for approval. Know docs don’t need 2 reviews, just >> > want to make sure the docs are good for users. >> > >> > PR is very example focused, shows limitations and work around! >> > >> > As with the giant over hall. I’m good with the approach. Patric and I >> > were talking about the doc build process when I first sent out the accord >> > PR, my hope is the output of this effort makes it easier to contribute / >> > validate than current trunk >> > >> > >> > Sent from my iPhone >> > >> > > On Apr 3, 2026, at 2:03 PM, Mick <[email protected]> wrote: >> > > >> > > >> > >> >> > >> The phasing in my mind was start with the content and then phase 2, >> > >> core build and deployment changes. For the users of Cassandra, my >> > >> initial big lift was giving them first class docs(and are they?) >> > >> >> > >> The items you mentioned are when I start moving things over to trunk, >> > >> and yes, there will be a lot of things to get th… >> > > >> > > >> > > >> > > My concern here is that you're putting the cart before the horse – you >> > > can't commit any of the new docs until you can build them the way they >> > > get built for the website. So, I guess, you have to be extra clear >> > > with folk that phase 1 is only content and layout review, and that those >> > > things may change and need to be reviewed again after phase 2. when the >> > > build is fixed/adapted. Take for example Scott's mention about >> > > rendering latex, that's moot because it can and will change again. >> > > >> > > If phase 1 is what you need as the driving force for motivation and to >> > > bring in collaboration, that's fine by me, just so long as everyone >> > > understands the above. >> > >
