drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: [VOTE] Drill bylaws
Date Tue, 07 Oct 2014 22:06:09 GMT
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 <tnachen@gmail.com> 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 <sphillips@maprtech.com>
> 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 <ted.dunning@gmail.com>
> 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 <julianhyde@gmail.com>
> 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 <jacques@apache.org>
> 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 <
> >> sphillips@maprtech.com>
> >>>> 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 <jacques@apache.org>
> >>> 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 <tshiran@gmail.com>
> >>> 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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message