Oh, interesting. I checked the doc and didn't see a time frame on the roll call but maybe I just missed it.
I'll open it up for comments either way. On Thu, Jun 4, 2020 at 5:51 PM Benedict Elliott Smith <bened...@apache.org> wrote: > I think the 24 hours point that was raised was pointed to being too short > was just for the roll-call; I personally that think for closing down a > discussion, 24 hours is acceptable in order to assist progress, since it > should only be called when it's clear the discussion has halted or > consensus has likely been reached. If in retrospect it appears that was > wrong, we can always cancel the vote. > > With regards to CEPs, I personally don't see any value in voting to start > one. There's nothing to stop proposers seeking advice, discussion and > collaborators beforehand, but voting on it seems premature until there's at > least some concrete proposal that's had some thought put into it, and an > initial round of wider discussion. There's already a community cost to the > process, too, and we don't want it to be overly burdensome. > > > On 04/06/2020, 22:39, "Joshua McKenzie" <jmcken...@apache.org> wrote: > > On the topic of CEP's, I'd advocate for us trying a couple/few out > first > and seeing what uncertainties arise as being troublesome and see if we > can't codify a best practice around them. To date we've had only a > couple > CEP's actively move and a few in draft pre-move pending more progress > on > 4.0 so I don't think we have enough signal on how they evolve to know > what > we might want to address through this doc. Does that make sense? > > 24 hours to close down lazy consensus does feel pretty quick by > default; I > think a default 72 hour with flexibility based on the topic (i.e. like > adding testing to the CEP guideline; super non-controversial) we can > just > run with things and revert if they're off. > > > Speaking of revert - that's one thing that was a real eye opener for me > personally philosophically in the past few weeks; git revert exists > for a > reason and if we all changed our posture to periodic reverts being a > healthy thing rather than shameful or contentious, we can all move a > lot > faster together in trust and revert when mistakes invariably happen. > Not > that we should start ninja'ing in 40k patches of course, but hopefully > the > point makes sense and resonates in terms of it being a continuum we're > perhaps quite extreme on culturally as a project. > > And we all have a sense for when something's more controversial, so we > have > CEP's to lean on. I dunno, makes sense in my head. :) > > On Thu, Jun 4, 2020 at 4:13 PM Mick Semb Wever <m...@apache.org> wrote: > > > > A link to the current draft of the governance doc is here: > > > > > > > > https://docs.google.com/document/d/1wOrJBkgudY2BxEVtubq9IbiFFC3d3efJSj9OIrGcqQ8/edit# > > > > > > The doc is only 2 pages long; if you're interested in engaging in a > > > discussion about how we evolve and collaborate as a project, > please take > > > some time to read through the doc, think through things, and > engage on > > this > > > thread here. > > > > > > > > Thanks Benedict and Josh. This is an awesome initiative to put out > in the > > open and include everyone in. > > > > My question is around the CEP lifecycle, how one is established and > how it > > exits (or moves into a real implementation stage). I guess that is an > > evolving discussion, and also depends on the nature of the > individual CEP. > > But it raises the questions of when do we apply the vote. For > example I can > > imagine two votes on a CEP: once to accept an CEP to start in > earnest, and > > a second time on the finalised CEP that the working group has > > finalised. As CEPs > > can evolve to quite a different place from their original idea. > Maybe we > > don't need that entry vote, as the document implies, but I'm not > entirely > > sure about that: i think some initial exposure and discussion can be > > valuable to prevent wasted adventures. > > > > regards, > > Mick > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
