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 <ctubb...@apache.org> 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 <busbey+li...@cloudera.com> > 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 <mad...@cloudera.com> 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 < > billie.rina...@gmail.com > >> >wrote: > >> > >> > On Thu, Apr 3, 2014 at 3:37 PM, Sean Busbey < > busbey+li...@cloudera.com > >> > >wrote: > >> > > >> > > On Thu, Apr 3, 2014 at 5:14 PM, Billie Rinaldi < > >> billie.rina...@gmail.com > >> > > >wrote: > >> > > > >> > > > On Thu, Apr 3, 2014 at 1:57 PM, Bill Havanki < > >> > bhava...@clouderagovt.com > >> > > > >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. > >> > > > >> > > >> >
