> maybe I just missed it
Haha, delicate __
This is what I get for trying to participate while aggressively time-boxing so
I can achieve other things. I imagined it entirely, and have confused
everyone; sorry Jordan and Josh.
On 05/06/2020, 00:03, "Joshua McKenzie" <jmcken...@apache.org> wrote:
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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org
For additional commands, e-mail: dev-h...@cassandra.apache.org
