Since feedback seems to be slowing down on this, how about we give it the weekend and if all things are still quiet, call a vote on it on Monday. Sound good?
Since we haven't yet ratified the structure and don't know our quorum on pmc, my initial idea is we go with "minimum of 7 +1 binding votes and no binding -1 votes", with binding defined as a pmc member vote given this is governance. Any concerns with this? Thanks again everyone for the time and energy on this. ~Josh On Thu, Jun 11, 2020 at 10:38 AM Joshua McKenzie <jmcken...@apache.org> wrote: > Integrated some feedback I got from Jon (good points both). Anyone else? > > On Wed, Jun 10, 2020 at 2:53 PM Joshua McKenzie <jmcken...@apache.org> > wrote: > >> Thanks for that insight Pavel. Will be a helpful and useful reference as >> we start to test out our CEP process after 4.0 solidifies. One thing that >> really stood out to me worth calling out: >>> >>> >>> >>> - Engage the wider Swift community in the ongoing evolution of >>> Swift, and >>> >>> >>> - Maintain the vision and conceptual coherence of Swift. >>> >>> There is a natural tension between these two goals. Open evolution >>> processes are, by nature, chaotic. Yet, maintaining a coherent vision for >>> something as complicated as a programming language requires some level of >>> coordination. The Swift evolution process aims to strike a balance that >>> best serves the Swift community as a whole. >> >> >> I'd love us to follow up on that topic (future vision, coherence, etc) on >> the project after we iron out our voting and governance process. >> >> So that being said - there's no further feedback on the doc in its >> current form. Anybody else have any thoughts on where things stand? >> >> >> On Wed, Jun 10, 2020 at 1:55 PM Pavel Yaskevich <pove...@gmail.com> >> wrote: >> >>> On Mon, Jun 8, 2020 at 3:12 AM Mick Semb Wever <m...@apache.org> 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. >>> > >>> > >>> > Totally agree that CEPs should be as light-weight as possible, and >>> with the >>> > sentiments above. But would also like to keep the discussion open to >>> > encourage and include as many voices as possible. >>> > >>> > My _questioning_ is around the value in "initial exposure and >>> discussion". >>> > It is implied already that there is lazy consensus in starting a CEP, >>> and >>> > that starting a CEP is more than just an initial proposal of an idea. >>> One >>> > example is we require a CEP to have a Shepherd that is a PMC member. >>> > Encouraging a vote, or better-yet keeping it light-weight: an initial >>> > DISCUSS thread as early as possible in the CEP lifecycle does come with >>> > value. From openly calling out for a Shepherd, to allowing the more >>> > experienced community members to add their insight (without having to >>> get >>> > formally involved in it), there's potential value in encouraging such >>> > open-mode opening discussion early on (versus the cost of additional >>> > process). >>> > >>> > Really interested in hearing from folk from other communities and >>> projects >>> > that do CEP/CIP and how their lifecycle through the process works and >>> what >>> > they have learnt. >>> > >>> >>> Here is a description of the process Swift Programming Language uses - >>> https://github.com/apple/swift-evolution/blob/master/process.md. >>> >>
