Timothy, The language in question is this:
Lazy approval (not counting the vote of the contributor), moving to lazy > majority if a -1 is received The meaning of this is that a commit goes forward if there is no -1 and at least one additional +1 is received. If there is a -1, then others can vote as well and if the number of +1's exceeds the number of -1's, then the commit goes forward. In practice, we should almost always have some discussion time before a commit. This should make -1 votes very, very rare. If they do occur, they will be a symptom is community disfunction and the primary priority at that point should be repair actions. On Tue, Oct 7, 2014 at 12:24 PM, Timothy Chen <[email protected]> wrote: > I see, wasn't really clear is this a general guideline our project is > going for or just a last resort enforcement. > > If this is the latter as Steven mentioned then I am fine as is. > > Tim > > Sent from my iPhone > > > On Oct 7, 2014, at 12:03 PM, Steven Phillips <[email protected]> > wrote: > > > > I agree with Ted. I feel like the by-laws are really a last resort, and > > generally speaking we won't be invoking the by-laws, and can operate in > de > > facto consensus mode. Only when it is clear that the consensus model is > not > > working would it become necessary to invoke the by-laws, call for a vote, > > and then move forward if there is a majority. > > > >> On Tue, Oct 7, 2014 at 11:44 AM, Ted Dunning <[email protected]> > wrote: > >> > >> I have seen situations where a previous quite reasonable committer > >> propagated issues from their personal life into their open source life. > >> Having a consensus requirement made a number of important forward steps > >> nearly impossible. The resulting unpleasantness is unavoidable to some > >> degree with any dispute, but when the one person has the ability to > >> propagate their private misery universally, it can nearly kill a > project. > >> > >> I would strongly recommend that consensus be the normal goal, but that > lazy > >> majority be the legislated requirement. Drill currently operates in a > >> review-then-commit mode in any case which should make vetoed commits > almost > >> unheard of in any case. > >> > >> > >> > >>> On Tue, Oct 7, 2014 at 11:15 AM, Julian Hyde <[email protected]> > wrote: > >>> > >>> I think Jacques is probably right and Lazy Consensus is better. I have > >> not > >>> experienced a crisis where a commit is contentious, so it’s > hypothetical > >>> for me. Changing my vote: > >>> > >>> 0 (binding) > >>> > >>> Julian > >>> > >>> > >>>> On Oct 7, 2014, at 9:14 AM, Jacques Nadeau <[email protected]> > wrote: > >>>> > >>>> I've given this some more thought and I think should fall back to Lazy > >>>> Conesus on code commits. Given that the community is still young and > >> we > >>>> have okay but not great diversity, I think it would be best if we made > >>> sure > >>>> that smaller contingents in the community are heard. I prefer to be > >>>> conservative in making sure each voice is heard early in the > >> development > >>> of > >>>> Drill. If we find that the project becomes gridlocked by this, it > >> would > >>> be > >>>> reasonable to update the bylaws to use a lazy majority fallback > >> instead. > >>>> > >>>> As such, I'm leaning towards a negative vote on the current bylaws. > >> That > >>>> said, I'd like to hear from others on how they feel about this. > >> Thoughts > >>>> people? > >>>> > >>>> Jacques > >>>> > >>>> On Mon, Oct 6, 2014 at 4:12 PM, Steven Phillips < > >> [email protected]> > >>>> wrote: > >>>> > >>>>> Lazy Majority seems fine to me. Do we really want to allow a single > >>>>> dissenting vote to hold up needed changes? > >>>>> > >>>>> It's possible at some point there me be a split in the community over > >>> the > >>>>> direction that Drill should take, and requiring consensus could > >> result > >>> in > >>>>> the project coming to a stand still. > >>>>> > >>>>> On Mon, Oct 6, 2014 at 4:00 PM, Jacques Nadeau <[email protected]> > >>> wrote: > >>>>> > >>>>>> I just got back after vacation so haven't had a chance to get caught > >> up > >>>>> on > >>>>>> email. > >>>>>> > >>>>>> What was the thinking of using Lazy approval > Lazy Majority versus > >>> using > >>>>>> Lazy Approval > Lazy Consensus for code changes? > >>>>>> > >>>>>> On Mon, Oct 6, 2014 at 3:50 PM, Tomer Shiran <[email protected]> > >>> wrote: > >>>>>> > >>>>>>> In order for Drill to graduate to a TLP, we need to finalize the > >>>>>> project's > >>>>>>> bylaws. Here's the latest proposal that has been shared/discussed > on > >>>>> this > >>>>>>> list: > >>>>>>> > >>>>>>> https://cwiki.apache.org/confluence/display/DRILL/Proposed+Bylaws > >>>>>>> > >>>>>>> The vote will be open for 72 hours. It will close on Oct 9, 4pm PT. > >>>>>>> > >>>>>>> [ ] +1 > >>>>>>> [ ] +0 > >>>>>>> [ ] -1 > >>>>>>> > >>>>>>> Please indicate whether your vote is binding or non-binding. > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Tomer > >>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Steven Phillips > >>>>> Software Engineer > >>>>> > >>>>> mapr.com > > > > > > > > -- > > Steven Phillips > > Software Engineer > > > > mapr.com >
