Integrated feedback from this thread thus far and responded to comments on the doc. Should be open to everyone for comment now.
On Thu, Jun 4, 2020 at 7:41 PM Jon Haddad <j...@jonhaddad.com> wrote: > > With regards to CEPs, I personally don't see any value in voting to start > one. > > Agree with this, and I'd go even further - requiring a vote in order to > propose an idea runs so counter to the idea of a CEP that it would default > the purpose of even having them. The CEP is the _proposal_ for a change > that gets fleshed out enough so people can understand the idea and _then_ > vote on it, not the other way around. > > On Thu, Jun 4, 2020 at 2: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 > > > > >
