http://deprecated-apache-flink-mailing-list-archive.368.s1.nabble.com/DISCUSS-Flink-project-bylaws-tp30409p30448.html
How different is this from the Kafka bylaws? I’m asking because I quite like them and wouldn’t mind essentially adopting the Kafka bylaws. I mean, it’s open source, and we don’t have to try to re-invent the wheel here.
I think it’s worthwhile to discuss the “committer +1” requirement. We don’t usually have that now but I would actually be in favour of requiring it, although it might make stuff more complicated.
> On 11. Jul 2019, at 15:31, Till Rohrmann <
[hidden email]> wrote:
>
> Thanks a lot for creating this draft Becket.
>
> I think without the notion of emeritus (or active vs. inactive), it won't
> be possible to have a 2/3 majority vote because we already have too many
> inactive PMCs/committers.
>
> For the case of a committer being the author and getting a +1 from a
> non-committer: I think a committer should know when to ask another
> committer for feedback or not. Hence, I would not enforce that we strictly
> need a +1 from a committer if the author is a committer but of course
> encourage it if capacities exist.
>
> Cheers,
> Till
>
> On Thu, Jul 11, 2019 at 3:08 PM Chesnay Schepler <
[hidden email]> wrote:
>
>> The emeritus stuff seems like unnecessary noise.
>>
>> There's a bunch of subtle changes in the draft compared to existing
>> "conventions"; we should find a way to highlight these and discuss them
>> one by one.
>>
>> On 11/07/2019 14:29, Robert Metzger wrote:
>>> Thank you Becket for kicking off this discussion and creating a draft in
>>> the Wiki.
>>>
>>> I left some comments in the wiki.
>>>
>>> In my understanding this means, that a committer always needs a review
>> and
>>>> +1 from another committer. As far as I know this is currently not always
>>>> the case (often committer authors, contributor reviews & +1s).
>>>
>>> I would agree to add such a bylaw, if we had cases in the past where code
>>> was not sufficiently reviewed AND we believe that we have enough capacity
>>> to ensure a separate committer's approval.
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jul 11, 2019 at 9:49 AM Konstantin Knauf <
>>
[hidden email]>
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> thanks a lot for driving this, Becket. I have two remarks regarding the
>>>> "Actions" section:
>>>>
>>>> * In addition to a simple "Code Change" we could also add a row for
>> "Code
>>>> Change requiring a FLIP" with a reference to the FLIP process page. A
>> FLIP
>>>> will have/does have different rules for approvals, etc.
>>>> * For "Code Change" the draft currently requires "one +1 from a
>> committer
>>>> who has not authored the patch followed by a Lazy approval (not counting
>>>> the vote of the contributor), moving to lazy majority if a -1 is
>> received".
>>>> In my understanding this means, that a committer always needs a review
>> and
>>>> +1 from another committer. As far as I know this is currently not always
>>>> the case (often committer authors, contributor reviews & +1s).
>>>>
>>>> I think it is worth thinking about how we can make it easy to follow the
>>>> bylaws e.g. by having more Flink-specific Jira workflows and ticket
>> types +
>>>> corresponding permissions. While this is certainly "Step 2", I believe,
>> we
>>>> really need to make it as easy & transparent as possible, otherwise they
>>>> will be unintentionally broken.
>>>>
>>>> Cheers and thanks,
>>>>
>>>> Konstantin
>>>>
>>>>
>>>>
>>>> On Thu, Jul 11, 2019 at 9:10 AM Becket Qin <
[hidden email]>
>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> As it was raised in the FLIP process discussion thread [1], currently
>>>> Flink
>>>>> does not have official bylaws to govern the operation of the project.
>>>> Such
>>>>> bylaws are critical for the community to coordinate and contribute
>>>>> together. It is also the basis of other processes such as FLIP.
>>>>>
>>>>> I have drafted a Flink bylaws page and would like to start a discussion
>>>>> thread on this.
>>>>>
>>>>
>>
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=120731026>>>>> The bylaws will affect everyone in the community. It'll be great to
>> hear
>>>>> your thoughts.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jiangjie (Becket) Qin
>>>>>
>>>>> [1]
>>>>>
>>>>>
>>>>
>>
http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/DISCUSS-META-FLIP-Sticking-or-not-to-a-strict-FLIP-voting-process-td29978.html#none>>>>
>>>> --
>>>>
>>>> Konstantin Knauf | Solutions Architect
>>>>
>>>> +49 160 91394525
>>>>
>>>>
>>>> Planned Absences: 10.08.2019 - 31.08.2019, 05.09. - 06.09.2010
>>>>
>>>>
>>>> --
>>>>
>>>> Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany
>>>>
>>>> --
>>>>
>>>> Ververica GmbH
>>>> Registered at Amtsgericht Charlottenburg: HRB 158244 B
>>>> Managing Directors: Dr. Kostas Tzoumas, Dr. Stephan Ewen
>>>>
>>
>>