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.
