I think the doc is a great place to reach agreement on things that are easily 
agreed - the final form will be moved to the wiki anyway, and voted on here.

Anything that isn't readily agreed should be moved here for further discussion, 
in my opinion, to widen participation.


On 04/06/2020, 22:41, "Joshua McKenzie" <jmcken...@apache.org> wrote:

    Also - would everyone like the doc opened up for comments so we can have
    localized feedback and discussion there? I think this ML thread might get
    hard to follow rapidly but I want to be mindful of apache policies
    surrounding things happening on the ML. I think closing out w/final time
    window and link here should be sufficient for records.

    Thoughts?

    On Thu, Jun 4, 2020 at 5:38 PM 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

Reply via email to