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
|