My understanding of this proposal is to add a section "User Guide" or "Operational Guide" to the CEP template and I support this. I don't think this is a big change to the CEP process, it's just a suggestion, not a mandatory section. It can be removed if not applicable to a particular CEP, but it would give proposers a chance to think through the operational implications of that change.
On Thu, Mar 26, 2026 at 5:20 PM Mick <[email protected]> wrote: > It is nice the CEP remains what we vote on, for the sake of governance. > > 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) > ? > 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… > > > > > > 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. > > > >
