The majority approval vote on version 1 of the bylaws passes. Because of the extensive discussion and vote changes, I will list each voter's final vote below. Please verify that my list is correct based on the vote's history prior to 1400 UTC (10 AM EDT / 7 AM PDT) today.
Sean: +1 Bill H: +1 Eric: +1 John: -1 Josh: +0 Christopher: -1 Mike: +0 Corey: +1 Brian: -0 Billie: -0 Totals: +1: 4 +0: 2 -0: 2 -1: 2 I will update the bylaw doc to version 1 and remove the draft statement. I will also fix the link that Sean found early on. Based on the vote history, and if there is no objection, I will also add to the doc (replacing the draft statement): Community work actively continues on the bylaws, and so key segments of them are subject to change. Thank you to everyone who voiced their opinions and voted. Bill H On Fri, Apr 4, 2014 at 9:20 AM, Billie Rinaldi <[email protected]>wrote: > Changing my vote to -0. I am personally neutral on whether we alter the > document before changing its version number or vice versa, but there > appears to be (informal) majority approval for fixing first. > > Regarding Christopher's comments, I think that using majority approval to > vote to change to consensus approval is internally consistent -- the people > who vote against believe in majority approval, so they should be okay with > the vote passing. It's the other direction that has problematic logic. > > > On Thu, Apr 3, 2014 at 8:15 PM, Christopher <[email protected]> wrote: > > > I don't know that the consensus vs. majority issue is fixable ex post > > facto... by establishing these bylaws, we're basically binding > > everybody in the community to a set of rules that is not in full > > agreement (with majority approval). Binding those who disagree to the > > rule that it is okay to proceed in spite of their disagreement seems a > > bit authoritarian. I understand that the initial vote was following > > the rules in the content of what was being voted on... and that makes > > sense to me, and I agree with it. However, given my concerns about > > binding dissenters to the same rules, with the sensible goal of using > > the established rules for establishing those same rules, it seems to > > me that full consensus is the only option that makes sense. > > > > If there were no other outstanding issues, I would say that we could > > move past this and change to consensus for modifying bylaws later... > > but then we're going to revisit this same chicken/egg problem then, > > but in a weird way: we'd be using majority voting to change to > > consensus voting. If there's minority dissent at that point, it'd > > still pass, but only by enacting a rule that would not have passed had > > the newly applied rule been in place. It seems to me that full > > consensus for initiating or modifying bylaws is the only sensible and > > internally consistent mechanism for voting on the bylaws themselves. > > > > The other issue, regarding clarification of wording around code > > changes I think can be fixed later. > > > > -- > > Christopher L Tubbs II > > http://gravatar.com/ctubbsii > > > > > > On Thu, Apr 3, 2014 at 8:14 PM, Sean Busbey <[email protected]> > > wrote: > > > Could the -1 voters please explain what we can't fix with a follow on > > > modification to the bylaws after this vote? > > > > > > Even on the matter of consensus vs majority approval for bylaw > > > modifications, it is relatively easy for a follow on vote to make this > > > change. It is no more difficult, say, than starting another vote after > > this > > > one fails. Certainly, it is easier than the reverse transition would > be. > > > > > > -Sean > > > > > > On Thu, Apr 3, 2014 at 6:43 PM, Mike Drob <[email protected]> wrote: > > > > > >> Changing my vote to +0. > > >> > > >> While I think the bylaws are fine as is, and I think future issues can > > be > > >> fixed through follow on amendments, there are clearly issues that have > > not > > >> been resolved. I would like to see strong adoption for the first pass, > > and > > >> then majority for future issues. > > >> > > >> > > >> On Thu, Apr 3, 2014 at 3:57 PM, Billie Rinaldi < > > [email protected] > > >> >wrote: > > >> > > >> > On Thu, Apr 3, 2014 at 3:37 PM, Sean Busbey < > > [email protected] > > >> > >wrote: > > >> > > > >> > > On Thu, Apr 3, 2014 at 5:14 PM, Billie Rinaldi < > > >> [email protected] > > >> > > >wrote: > > >> > > > > >> > > > On Thu, Apr 3, 2014 at 1:57 PM, Bill Havanki < > > >> > [email protected] > > >> > > > >wrote: > > >> > > > > > >> > > > > > >> > > > Going by the standards of a release vote, voting is actually the > > >> > > > appropriate time to discover fundamental issues. That's kind of > > the > > >> > > whole > > >> > > > point of voting -- getting people to agree that there are no > > >> > fundamental > > >> > > > issues with what you're voting on. Finding valid, justifiable > > issues > > >> > > > should be welcome, as it results in a better product, whether > the > > >> > product > > >> > > > be a release or a community standard. > > >> > > > > > >> > > > > > >> > > > > > >> > > As an aside, this is not encouraged in our current release > process. > > >> > > > > >> > > The test practices for a release take longer than the voting > period > > for > > >> > an > > >> > > RC. This directly implies that the fundamental issues must have > been > > >> > worked > > >> > > out prior to a call to vote. > > >> > > > > >> > > > >> > Our disagreement here might largely be due to differing definitions > of > > >> > "fundamental issues." Also, I think you might be blocking out what > > >> > happened between the first 1.5.0 release candidate and the last? =) > > >> > > > >> > > > >> > > > > >> > > I've been fine with this interpretation, largely because it lines > up > > >> with > > >> > > Apache guidelines around votes: do the consensus building work up > > >> front. > > >> > If > > >> > > we're going to use a release vote as a time to do primary vetting, > > then > > >> > we > > >> > > should probably change our RC vote window. > > >> > > > > >> > > > >> > > > -- // Bill Havanki // Solutions Architect, Cloudera Govt Solutions // 443.686.9283
