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
