> There are counter-examples > for a somewhat formal proposal process Yeah. The process was originally conceived as a lightweight "get early buy-in for something that might be controversial before you invest too much work in it". In practice that's turned into swinging the pendulum a bit too far in the opposite direction from where we used to be, which was "people drop giant code-bombs on the project that nobody else can meaningfully review or comment on because months or years of engineering is already done".
I'm personally coming around to the stance that most successful CEP's are either a) pretty non-controversial (so arguably don't even need the CEP process), or b) come with a fleshed out prototype proving the viability and value of the thing the proposer wants to add. That concrete artifact both improves the design communicated in the CEP and significantly raises the bar re: rigor required to engage in discussion; if someone's floating a CEP that's a set of well thought out designs, that's easier to poke holes in and take potshots at from the peanut gallery compared to a CEP that also has a prototype bundled with it showing it working. Anyway - not a huge deal, and I think we're fine either way (CEP w/out JIRA, CEP w/JIRA that may get closed out as "Won't Do"). On Thu, Jul 17, 2025, at 12:40 PM, Joel Shepherd wrote: > FWIW, to my naive mind it makes sense to follow a process like: 1) Propose, > 2) Discuss, 3) Vote (if discussion closes out w/o controversy 4) Adopt (if > vote passes), 5) Cut the top-level JIRA. Creating the JIRA is the call to > action for performing the work (at some point): it probably makes sense to > not issue the call to action until the community has agreed that the action > is reasonable and desirable. > > There are counter-examples though: e.g. > https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=263425995 > and > https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-38%3A+CQL+Management+API > . So I didn't hesitate much in creating the JIRA, thinking maybe there are > good if undocumented reasons for doing so. Apologies if it created noise. > > My instinct though is that for a somewhat formal proposal process, it's > probably best to let the process run its course before kick-starting the > mechanisms for tracking the actual implementation. > > Thanks -- Joel. > > On 7/17/2025 8:08 AM, guo Maxwell wrote: >> We should reach a consensus on the CEP, and then we can adjust the status of >> Jira to open. If everyone feels that there is no need to start this CEP, >> then Jira either does not need to be created or there is no need to set it >> to open. >> >> I think the order to set the jira‘s status is more important than create. >> >> Josh McKenzie <jmcken...@apache.org>于2025年7月17日 周四下午10:42写道： >>> I *may* have led Joel astray re: ordering on CEP-50 and >>> https://issues.apache.org/jira/browse/CASSANDRA-20768. >>> >>> I always thought we created JIRAs proactively to go along w/a CEP and just >>> closed out the JIRA if we couldn't get to an agreement on things. Mostly >>> just because of my anal retentive reflex to expect there to be a linked >>> JIRA in the CEP wiki article (which of course adds no value until the CEP >>> discussion and vote have passed...). Though in cases where there's >>> prototype code or artifacts to go along w/a CEP, I think having a JIRA for >>> that makes sense. >>> >>> Anyway - anyone have any opinions here? I don't think it's important enough >>> to codify anything, just wondering if I should recalibrate my own >>> assumptions around that structure so I don't potentially lead future people >>> astray.
