Re: [DISCUSS] governance on the Apache Cassandra project
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 wrote: > Integrated some feedback I got from Jon (good points both). Anyone else? > > On Wed, Jun 10, 2020 at 2:53 PM Joshua McKenzie > 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 >> wrote: >> >>> On Mon, Jun 8, 2020 at 3:12 AM Mick Semb Wever 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. >>> >>
Re: [DISCUSS] governance on the Apache Cassandra project
Thanks for the insight Jun. It's great to hear that a process that's erring on the side of flexibility, freedom, and under-prescription holds up well in practice! Have you folks run into any trouble w/lack of alignment (false negatives or positives) on what qualifies as major? > >- Any major new feature, subsystem, or piece of functionality > > On Thu, Jun 11, 2020 at 2:42 PM Jun Rao wrote: > Hi, everyone, > > Just want to briefly share our experience in Apache Kafka. This may or may > not apply to the Cassandra community. > > We started the KIP ( > > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals > ) > process in 2015. The following is the summary of the process. > > 1. It's designed for major new features or changes to public interfaces. > 2. Anyone can start a KIP as long as that person has the intention to carry > it through. > 3. The KIP first goes through a discussion phase and then a voting phase. > The vote requires +1 from at least 3 committers to pass. > > Overall, I think our experience with KIP is positive. It (a) made our > compatibility story much better since more people are paying attention to > public interface changes; (2) allowed major features to be discussed more > thoroughly and often made the original proposal better; (3) non-relevant > KIPs (e.g. covered by existing features or other KIPs) were mostly vetted > out in the early discussion phase. > > We made some minor adjustments along the way. For example, if minor changes > are later discovered during the implementation of an accepted KIP, those > changes can just be added to the voting thread. If there are no objections, > those changes are accepted without the need of a new vote. > > Sometimes, it does feel that KIP adds a bit overhead. For example, changing > a simple configuration requires the same multi-day process. However, that's > probably minor given the overall benefits. > > Thanks, > > Jun >
Re: [DISCUSS] governance on the Apache Cassandra project
Hi, everyone, Just want to briefly share our experience in Apache Kafka. This may or may not apply to the Cassandra community. We started the KIP ( https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals) process in 2015. The following is the summary of the process. 1. It's designed for major new features or changes to public interfaces. 2. Anyone can start a KIP as long as that person has the intention to carry it through. 3. The KIP first goes through a discussion phase and then a voting phase. The vote requires +1 from at least 3 committers to pass. Overall, I think our experience with KIP is positive. It (a) made our compatibility story much better since more people are paying attention to public interface changes; (2) allowed major features to be discussed more thoroughly and often made the original proposal better; (3) non-relevant KIPs (e.g. covered by existing features or other KIPs) were mostly vetted out in the early discussion phase. We made some minor adjustments along the way. For example, if minor changes are later discovered during the implementation of an accepted KIP, those changes can just be added to the voting thread. If there are no objections, those changes are accepted without the need of a new vote. Sometimes, it does feel that KIP adds a bit overhead. For example, changing a simple configuration requires the same multi-day process. However, that's probably minor given the overall benefits. Thanks, Jun
Re: [DISCUSS] governance on the Apache Cassandra project
Integrated some feedback I got from Jon (good points both). Anyone else? On Wed, Jun 10, 2020 at 2:53 PM Joshua McKenzie 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 wrote: > >> On Mon, Jun 8, 2020 at 3:12 AM Mick Semb Wever 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. >> >
Re: [DISCUSS] governance on the Apache Cassandra project
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 wrote: > On Mon, Jun 8, 2020 at 3:12 AM Mick Semb Wever 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. >
Re: [DISCUSS] governance on the Apache Cassandra project
On Mon, Jun 8, 2020 at 3:12 AM Mick Semb Wever 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.
Re: [DISCUSS] governance on the Apache Cassandra project
I've tightened up some of the verbiage and also updated the doc to be consistent w/the current CEP procedures on the wiki re: voting and ratifying. As always, more feedback is welcome. On Mon, Jun 8, 2020 at 9:38 AM Joshua McKenzie wrote: > One example is we require a CEP to have a Shepherd that is a PMC member > > This should be revised from "PMC member" to "committer" > > > On Mon, Jun 8, 2020 at 6:12 AM Mick Semb Wever 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. >> >
Re: [DISCUSS] governance on the Apache Cassandra project
> > One example is we require a CEP to have a Shepherd that is a PMC member This should be revised from "PMC member" to "committer" On Mon, Jun 8, 2020 at 6:12 AM Mick Semb Wever 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. >
Re: [DISCUSS] governance on the Apache Cassandra project
> > 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.
Re: [DISCUSS] governance on the Apache Cassandra project
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 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 > > 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" 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 > 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,
Re: [DISCUSS] governance on the Apache Cassandra project
> 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 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" 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 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 > >
Re: [DISCUSS] governance on the Apache Cassandra project
> 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" 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 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" 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 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
Re: [DISCUSS] governance on the Apache Cassandra project
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 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" 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 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 > >
Re: [DISCUSS] governance on the Apache Cassandra project
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" 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 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
Re: [DISCUSS] governance on the Apache Cassandra project
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" 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 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 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
Re: [DISCUSS] governance on the Apache Cassandra project
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 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 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 >> >
Re: [DISCUSS] governance on the Apache Cassandra project
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 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 >
Re: [DISCUSS] governance on the Apache Cassandra project
> 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
Re: [DISCUSS] governance on the Apache Cassandra project
> It seems all rules on voting are predicated on the question being binary ASF votes are meant to be - as far as possible - a formality confirming consensus, or something to resolve irreconcilable disagreements. The discussion section describes how to build consensus when there are multiple options, or multiple areas of disagreement on a proposal, by using indicative votes (with multiple options, via e.g. instant runoff), that are not binding and can be used to modify the proposal so that the vote is on a binary question with broad support. > Regarding the PMC roll call, is there any definition of "active on the > project and want to participate"? There are a lot of points to nail down, and the roll call was something that only barely squeezed a win in indicative votes on the private list, and is very much still up for debate - including the window (a week would also seem fine). There's also a question over the vote floor, both for procedural and CEP votes. There was a clear majority for super-majority decisions, and for determining the "active electorate" by _some_ mechanism (dev@ and private@ participation were discussed as well), but to avoid perverse voting incentives we need to determine a floor for _votes in favour_ rather than _participants_, else we disincentivise voting against proposals that have not yet reached a quorum. The proposal currently requires a super-majority of the "active electorate" as well, but this is probably too strong, and simple majority of the active electorate, plus super-majority of voters is probably more than sufficient to claim consensus. > Will the PMC roll call apply to the PMC itself? That was my original read of > it but looking closer, its an email to dev@. That's the idea, but we're aiming to keep as much in public as possible. > The bar regarding code review This is another whole rabbit hole of a discussion, but: - I agree that we should carve out some extra cheap consensus options, such as perhaps tests; if we can source a community list of clearly defined items that would be great - The 2 +1 votes does not mean both need to have reviewed the change, it just means that two committers have taken a look and agreed adequate work appears to have been done; a skim of the patch and knowledge of the experience of the proposer and reviewer will often suffice, but it means new contributors and relatively junior committers are less likely to accidentally commit something with wider ramifications than they realise. The practical implications should be minimal. I have tried to clarify that in the document, with a separate item expressly requiring one review for all changes. - I hope to strengthen the requirement to 3 + 1 votes, at least two of which committers, with at least two concrete reviews for any moderate complexity work, but this is for another discussion On 04/06/2020, 18:29, "Murukesh Mohanan" wrote: A couple of thoughts: 1. It seems all rules on voting are predicated on the question being binary. Perhaps we should also tack on a section for cases where we have to pick among multiple options (a simple plurality, maybe). 2. Should this itself be a CEP? (E.g., Python's governance model was proposed in PEPs 8010 through 8016 ([1][2] etc.) and codified in PEP 13 [3], PHP's voting system was iterated upon recently in their equivalent, an RFC [4]) Or perhaps not, since the current CEP description suggests that CEPs are exclusively for code changes? (If that's the case, we could discuss that at a later date, and move on with this proposal first.) [1]: https://www.python.org/dev/peps/pep-8015/ [2]: https://www.python.org/dev/peps/pep-8016/ [3]: https://www.python.org/dev/peps/pep-0013/ [4]: https://wiki.php.net/rfc/abolish-narrow-margins Yours, Murukesh Mohanan On Fri, 5 Jun 2020 at 01:54, Joshua McKenzie wrote: > Hello project! > > The pmc has been discussing how we make decisions as a pmc, how we make > decisions as a project of committers and contributors, what decisions are > made where, and how those decisions are ratified and by whom. We came to > the conclusion that there's value in having a more formal (though > lightweight) structure around these topics as well as start to enumerate > some expectations on how we interact with each other on the project as it > matures. > > 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 everyone, and looking forward to a great discussion! > > ~Josh McKenzie >
Re: [DISCUSS] governance on the Apache Cassandra project
I missed the end of Josh's email that suggested engaging here and the doc doesn't allow comments anyways so some more questions / thoughts here: - Regarding the PMC roll call, is there any definition of "active on the project and want to participate"? - Will the PMC roll call apply to the PMC itself? That was my original read of it but looking closer, its an email to dev@. - 24 hour periods seem a little short, especially on the weekends - The bar regarding code review: I am generally +1 on requiring more eyes on code review. Two areas that I think could use clarification: for low-risk patches like test fixes, etc it may be too strong and for high risk patches the caveat that the author can be a reviewer if also a committer is too weak. I'll start with those 4 to limit the potential branching of this thread. Jordan On Thu, Jun 4, 2020 at 12:06 PM Jordan West wrote: > Glad to see the PMC has been discussing these topics and is making efforts > towards improving on the status quo. Thanks for sharing the draft. I'll > leave more detailed questions/comments on the doc itself but as a whole its > encouraging to see the PMC rely more heavily on the community and make an > effort to keep its view of active participants current. > > Jordan > > On Thu, Jun 4, 2020 at 9:54 AM Joshua McKenzie > wrote: > >> Hello project! >> >> The pmc has been discussing how we make decisions as a pmc, how we make >> decisions as a project of committers and contributors, what decisions are >> made where, and how those decisions are ratified and by whom. We came to >> the conclusion that there's value in having a more formal (though >> lightweight) structure around these topics as well as start to enumerate >> some expectations on how we interact with each other on the project as it >> matures. >> >> 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 everyone, and looking forward to a great discussion! >> >> ~Josh McKenzie >> >
Re: [DISCUSS] governance on the Apache Cassandra project
Glad to see the PMC has been discussing these topics and is making efforts towards improving on the status quo. Thanks for sharing the draft. I'll leave more detailed questions/comments on the doc itself but as a whole its encouraging to see the PMC rely more heavily on the community and make an effort to keep its view of active participants current. Jordan On Thu, Jun 4, 2020 at 9:54 AM Joshua McKenzie wrote: > Hello project! > > The pmc has been discussing how we make decisions as a pmc, how we make > decisions as a project of committers and contributors, what decisions are > made where, and how those decisions are ratified and by whom. We came to > the conclusion that there's value in having a more formal (though > lightweight) structure around these topics as well as start to enumerate > some expectations on how we interact with each other on the project as it > matures. > > 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 everyone, and looking forward to a great discussion! > > ~Josh McKenzie >
Re: [DISCUSS] governance on the Apache Cassandra project
A couple of thoughts: 1. It seems all rules on voting are predicated on the question being binary. Perhaps we should also tack on a section for cases where we have to pick among multiple options (a simple plurality, maybe). 2. Should this itself be a CEP? (E.g., Python's governance model was proposed in PEPs 8010 through 8016 ([1][2] etc.) and codified in PEP 13 [3], PHP's voting system was iterated upon recently in their equivalent, an RFC [4]) Or perhaps not, since the current CEP description suggests that CEPs are exclusively for code changes? (If that's the case, we could discuss that at a later date, and move on with this proposal first.) [1]: https://www.python.org/dev/peps/pep-8015/ [2]: https://www.python.org/dev/peps/pep-8016/ [3]: https://www.python.org/dev/peps/pep-0013/ [4]: https://wiki.php.net/rfc/abolish-narrow-margins Yours, Murukesh Mohanan On Fri, 5 Jun 2020 at 01:54, Joshua McKenzie wrote: > Hello project! > > The pmc has been discussing how we make decisions as a pmc, how we make > decisions as a project of committers and contributors, what decisions are > made where, and how those decisions are ratified and by whom. We came to > the conclusion that there's value in having a more formal (though > lightweight) structure around these topics as well as start to enumerate > some expectations on how we interact with each other on the project as it > matures. > > 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 everyone, and looking forward to a great discussion! > > ~Josh McKenzie >
[DISCUSS] governance on the Apache Cassandra project
Hello project! The pmc has been discussing how we make decisions as a pmc, how we make decisions as a project of committers and contributors, what decisions are made where, and how those decisions are ratified and by whom. We came to the conclusion that there's value in having a more formal (though lightweight) structure around these topics as well as start to enumerate some expectations on how we interact with each other on the project as it matures. 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 everyone, and looking forward to a great discussion! ~Josh McKenzie
