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
