drill-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomer Shiran <tshi...@gmail.com>
Subject Re: [VOTE] Drill bylaws
Date Wed, 08 Oct 2014 21:29:19 GMT
I would like to propose that we adopt the rule used by the Hadoop project
which is that code should not be committed if there are committers that -1
it, but that only a single +1 is needed (from a committer). This model has
proven to work well in a diverse community. Clearly there's a tradeoff
between wanting to prevent one person from being able to prevent progress,
and keeping the project collaborative and 'under control'. Given Drill's
focus on providing a great user experience, I think that having stronger
controls in place makes sense. As you can see, this has been our modus
operandi to date and it has not prevented progress at all.

Please review the new language here:
https://cwiki.apache.org/confluence/display/DRILL/Proposed+Bylaws

I would like to restart the vote tomorrow.

On Tue, Oct 7, 2014 at 3:06 PM, Ted Dunning <ted.dunning@gmail.com> wrote:

> 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