I'm a big fan of the idea of having this on new CEPs. To Paulo's point about the section being optional: I agree that this section may not be applicable to many CEPs, but I think it's worth explicitly calling out why it's not. In that sense, it's still optional but taken into consideration when discussing the CEP.
On Thu, Mar 26, 2026 at 5:47 PM Joel Shepherd <[email protected]> wrote: > On 3/26/2026 2:20 PM, Mick wrote: > > It is nice the CEP remains what we vote on, for the sake of governance. > > Makes sense. What would you think of allowing an explicit "Addendum" or > "Errata" section where refinements or needed changes are discovered > during implementation? And maybe an expectation that updates to those > will be announced on this list so folks can review. That'll preserve the > original proposal as it was accepted, yet allow for evolution as plans > meet reality. > > > is the "user experience" (or "operational guide") part of what we vote > on ? is it as fixed as the rest of the cep doc (the input in/before the > impl) ? > > I personally think it should be. For the author, it's a forcing function > for thinking through the operator experience up-front, which will > probably result in a better operator experience, and that in turn will > make Cassandra more appealing to current and future users. > > For the reader/reviewer, it's an early opportunity to decide if they'll > actually be able to use the feature as proposed, or if there are > operational risks that they're not comfortable with. > > > if not, would it be better somewhere else ? > > i can see the need for both "here's a permanent copy of the CEP as it > was voted on" and "here's how it ended up, with extra docs", but I don't > know how/where the latter goes… > > Yeah: I'll withdraw my comment about "retro-fitting" -- I didn't think > about that in terms of changing the voted-on proposal -- but since the > CEP often seems to be the comprehensive* source of information about a > feature/capability, it seems like a good place for information about how > to use the thing. > > Thanks -- Joel. > > * - Despite the use of the word "comprehensive" as well as em dashes, > this e-mail was composed entirely by a human and not an AI agent. ;-) > > >> On 26 Mar 2026, at 19:31, Joel Shepherd <[email protected]> wrote: > >> > >> Hi all - I wonder if there would be community support for including a > "user experience" section in CEPs going forward (no rules against > retro-fitting them either). > >> > >> The purpose of the section would be to describe how an operator would > be expected to enable, configure, upgrade (if necessary) and operate the > feature proposed in the CEP. > >> > >> Paulo wrote an "Operational Guide" section in CEP-62, which I found > helpful in getting a clear picture about what my responsibilities would be, > as an operator, if I wanted to use Sidecar to manage my node config. As I'm > working through the implementation of CEP-50, I'm also realizing that > operators are going to need to understand how to configure negotiation and > know about things that will end up either being sharp edges or fundamental > changes in behavior. (Did you know that unauthenticated, anonymous users > are by default super-users? Holy Privilege Escalation, Batman!) > >> > >> I plan to add an "Operational Guide" section to CEP-50 and probably > revise it as I better understand the implications of some of the changes > required. I think in general doing so as early as possible will get us to > think early about how easy or hard it will be for Cassandra users to adopt > new functionality, and hopefully push the project as a whole towards making > it as easy as possible. > >> > >> Thoughts? > >> > >> -- Joel. > >> >
