[DISCUSS] Flink project bylaws

[Becket Qin]

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-3]

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

[phone]


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

[Robert Metzger]

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
>
> [phone]
>
>
> 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
>

[Chesnay Schepler-3]

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
>>
>> [phone]
>>
>>
>> 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
>>

[Till Rohrmann]

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
> >>
> >> [phone]
> >>
> >>
> >> 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
> >>
>
>

[Aljoscha Krettek-2]

Big +1

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.

Aljoscha

> 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
>>>>
>>>> [phone]
>>>>
>>>>
>>>> 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
>>>>
>>
>>

[Becket Qin]

Thanks everyone for all the comments and feedback. Please see the replies
below:

--------------------------------
Re: Konstantin

> * 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.


Good point. Just added the entry.

-------------------------------
Re: Konstantin

> * 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.


& Re: Till

> 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.


I am with Robert and Aljoscha on this.

I completely understand the concern here. TBH, in Kafka occasionally
trivial patches from committers are still merged without following the
cross-review requirement, but it is rare. That said, I still think an
additional committer's review makes sense due to the following reasons:
1. The bottom line here is that we need to make sure every patch is
reviewed with a high quality. This is a little difficult to guarantee if
the review comes from a contributor for many reasons. In some cases, a
contributor may not have enough knowledge about the project to make a good
judgement. Also sometimes the contributors are more eagerly to get a
particular issue fixed, so they are willing to lower the review bar.
2. One byproduct of such cross review among committers, which I personally
feel useful, is that it helps gradually form consistent design principles
and code style. This is because the committers will know how the other
committers are writing code and learn from each other. So they tend to
reach some tacit understanding on how things should be done in general.

Another way to think about this is to consider the following two scenarios:
1. Reviewing a committer's patch takes a lot of iterations. Then the patch
needs to be reviewed even if it takes time because there are things
actually needs to be clarified / changed.
2. Reviewing a committer's patch is very smooth and quick, so the patch is
merged soon. Then reviewing such a patch does not take much time.

Letting another committer review the patch from a committer falls either in
case 1 or case 2. The best option here is to review the patch because
If it is case 1, the patch actually needs to be reviewed.
If it is case 2, the review should not take much time anyways.

In the contrast, we will risk encounter case 1 if we skip the cross-review.

------------------------
Re: Robert

I replied to your comments in the wiki and made the following modifications
to resolve some of your comments:
1. Added a release manager role section.
2. changed the name of "lazy consensus" to "consensus" to align with
general definition of Apache glossary and other projects.
3. review board  -> pull request

-------------------------
Re: Chesnay

The emeritus stuff seems like unnecessary noise.
>
As Till mentioned, this is to make sure 2/3 majority is still feasible in
practice.

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.

That is a good suggestion. I am not familiar enough with the current Flink
convention. Will you help on this? I saw you commented on some part in the
wiki. Are those complete?

--------------------------
 Re: Aljoscha

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.

Ha, you got me on this. The first version of the draft was almost identical
to Kafka. But Robert has already caught a few inconsistent places. So it
might still worth going through it to make sure we truly agree on them.
Otherwise we may end up modifying them shortly after adoption.


Thanks again folks, for all the valuable feedback. These are great
discussion.

Jiangjie (Becket) Qin

On Thu, Jul 11, 2019 at 9:55 PM Aljoscha Krettek <[hidden email]>
wrote:

> Big +1
>
> 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.
>
> Aljoscha
>
> > 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
> >>>>
> >>>> [phone]
> >>>>
> >>>>
> >>>> 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
> >>>>
> >>
> >>
>
>

[bowen.li]

On Thu, Jul 11, 2019 at 10:38 AM Becket Qin <[hidden email]> wrote:

> Thanks everyone for all the comments and feedback. Please see the replies
> below:
>
> --------------------------------
> Re: Konstantin
>
> > * 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.
>
>
> Good point. Just added the entry.
>
> -------------------------------
> Re: Konstantin
>
> > * 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.
>
>
> & Re: Till
>
> > 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.
>
>
> I am with Robert and Aljoscha on this.
>
> I completely understand the concern here. TBH, in Kafka occasionally
> trivial patches from committers are still merged without following the
> cross-review requirement, but it is rare. That said, I still think an
> additional committer's review makes sense due to the following reasons:
> 1. The bottom line here is that we need to make sure every patch is
> reviewed with a high quality. This is a little difficult to guarantee if
> the review comes from a contributor for many reasons. In some cases, a
> contributor may not have enough knowledge about the project to make a good
> judgement. Also sometimes the contributors are more eagerly to get a
> particular issue fixed, so they are willing to lower the review bar.
> 2. One byproduct of such cross review among committers, which I personally
> feel useful, is that it helps gradually form consistent design principles
> and code style. This is because the committers will know how the other
> committers are writing code and learn from each other. So they tend to
> reach some tacit understanding on how things should be done in general.
>
> Another way to think about this is to consider the following two scenarios:
> 1. Reviewing a committer's patch takes a lot of iterations. Then the patch
> needs to be reviewed even if it takes time because there are things
> actually needs to be clarified / changed.
> 2. Reviewing a committer's patch is very smooth and quick, so the patch is
> merged soon. Then reviewing such a patch does not take much time.
>
> Letting another committer review the patch from a committer falls either in
> case 1 or case 2. The best option here is to review the patch because
> If it is case 1, the patch actually needs to be reviewed.
> If it is case 2, the review should not take much time anyways.
>
> In the contrast, we will risk encounter case 1 if we skip the cross-review.
>
> ------------------------
> Re: Robert
>
> I replied to your comments in the wiki and made the following modifications
> to resolve some of your comments:
> 1. Added a release manager role section.
> 2. changed the name of "lazy consensus" to "consensus" to align with
> general definition of Apache glossary and other projects.
> 3. review board  -> pull request
>
> -------------------------
> Re: Chesnay
>
> The emeritus stuff seems like unnecessary noise.
> >
> As Till mentioned, this is to make sure 2/3 majority is still feasible in
> practice.
>
> 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.
>
> That is a good suggestion. I am not familiar enough with the current Flink
> convention. Will you help on this? I saw you commented on some part in the
> wiki. Are those complete?
>
> --------------------------
>  Re: Aljoscha
>
> 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.
>
> Ha, you got me on this. The first version of the draft was almost identical
> to Kafka. But Robert has already caught a few inconsistent places. So it
> might still worth going through it to make sure we truly agree on them.
> Otherwise we may end up modifying them shortly after adoption.
>
>
> Thanks again folks, for all the valuable feedback. These are great
> discussion.
>
> Jiangjie (Becket) Qin
>
> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha Krettek <[hidden email]>
> wrote:
>
> > Big +1
> >
> > 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.
> >
> > Aljoscha
> >
> > > 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
> > >>>>
> > >>>> [phone]
> > >>>>
> > >>>>
> > >>>> 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
> > >>>>
> > >>
> > >>
> >
> >
>

[Chesnay Schepler-3]

I'm wondering whether we shouldn't first write down Bylaws that reflect
the current state, and then have separate discussions for individual
amendments. My gut feeling is that this discussion will quickly become a
chaotic mess with plenty points being discussed at once.

On 11/07/2019 20:03, Bowen Li wrote:

> On Thu, Jul 11, 2019 at 10:38 AM Becket Qin <[hidden email]> wrote:
>
>> Thanks everyone for all the comments and feedback. Please see the replies
>> below:
>>
>> --------------------------------
>> Re: Konstantin
>>
>>> * 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.
>>
>> Good point. Just added the entry.
>>
>> -------------------------------
>> Re: Konstantin
>>
>>> * 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.
>>
>> & Re: Till
>>
>>> 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.
>>
>> I am with Robert and Aljoscha on this.
>>
>> I completely understand the concern here. TBH, in Kafka occasionally
>> trivial patches from committers are still merged without following the
>> cross-review requirement, but it is rare. That said, I still think an
>> additional committer's review makes sense due to the following reasons:
>> 1. The bottom line here is that we need to make sure every patch is
>> reviewed with a high quality. This is a little difficult to guarantee if
>> the review comes from a contributor for many reasons. In some cases, a
>> contributor may not have enough knowledge about the project to make a good
>> judgement. Also sometimes the contributors are more eagerly to get a
>> particular issue fixed, so they are willing to lower the review bar.
>> 2. One byproduct of such cross review among committers, which I personally
>> feel useful, is that it helps gradually form consistent design principles
>> and code style. This is because the committers will know how the other
>> committers are writing code and learn from each other. So they tend to
>> reach some tacit understanding on how things should be done in general.
>>
>> Another way to think about this is to consider the following two scenarios:
>> 1. Reviewing a committer's patch takes a lot of iterations. Then the patch
>> needs to be reviewed even if it takes time because there are things
>> actually needs to be clarified / changed.
>> 2. Reviewing a committer's patch is very smooth and quick, so the patch is
>> merged soon. Then reviewing such a patch does not take much time.
>>
>> Letting another committer review the patch from a committer falls either in
>> case 1 or case 2. The best option here is to review the patch because
>> If it is case 1, the patch actually needs to be reviewed.
>> If it is case 2, the review should not take much time anyways.
>>
>> In the contrast, we will risk encounter case 1 if we skip the cross-review.
>>
>> ------------------------
>> Re: Robert
>>
>> I replied to your comments in the wiki and made the following modifications
>> to resolve some of your comments:
>> 1. Added a release manager role section.
>> 2. changed the name of "lazy consensus" to "consensus" to align with
>> general definition of Apache glossary and other projects.
>> 3. review board  -> pull request
>>
>> -------------------------
>> Re: Chesnay
>>
>> The emeritus stuff seems like unnecessary noise.
>> As Till mentioned, this is to make sure 2/3 majority is still feasible in
>> practice.
>>
>> 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.
>> That is a good suggestion. I am not familiar enough with the current Flink
>> convention. Will you help on this? I saw you commented on some part in the
>> wiki. Are those complete?
>>
>> --------------------------
>>   Re: Aljoscha
>>
>> 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.
>> Ha, you got me on this. The first version of the draft was almost identical
>> to Kafka. But Robert has already caught a few inconsistent places. So it
>> might still worth going through it to make sure we truly agree on them.
>> Otherwise we may end up modifying them shortly after adoption.
>>
>>
>> Thanks again folks, for all the valuable feedback. These are great
>> discussion.
>>
>> Jiangjie (Becket) Qin
>>
>> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha Krettek <[hidden email]>
>> wrote:
>>
>>> Big +1
>>>
>>> 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.
>>>
>>> Aljoscha
>>>
>>>> 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
>>>>>>>
>>>>>>> [phone]
>>>>>>>
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>
>>>

[Piotr Nowojski-3]

Hi,

Thanks for the proposal. Generally speaking +1 from my side to the general idea and most of the content. I also see merit to the Chesney's proposal to start from the current state. I think either would be fine for me.

Couple of comments:

1.

I also think that requiring +1 from another committer would slow down and put even more strain on the current reviewing bottleneck that we are having. Even if the change clear and simple, context switch cost is quite high, and that’s just one less PR that the second “cross” committer could have reviewed somewhere else in that time. Besides, current setup that we have (with no cross +1 from another committer required) works quite well and I do not feel that’s causing troubles. On the other hand reviewing bottleneck is.

2.

> I think a committer should know when to ask another committer for feedback or not.

I’m missing this stated somewhere clearly. If we are stating that a single committers +1 is good enough for code review, with 0 hours delay (de facto the current state), we should also write down that this is subject to the best judgement of the committer to respect the components expertise and ongoing development plans (also the de facto current state).

3.

Minimum length of 3 days for FLIP I think currently might be problematic/too quick and can lead to problems if respected to the letter. Again I think it depends highly on whether the committers with highest expertise in the affected components managed to respond or not.

Piotrek

> On 12 Jul 2019, at 09:42, Chesnay Schepler <[hidden email]> wrote:
>
> I'm wondering whether we shouldn't first write down Bylaws that reflect the current state, and then have separate discussions for individual amendments. My gut feeling is that this discussion will quickly become a chaotic mess with plenty points being discussed at once.
>
> On 11/07/2019 20:03, Bowen Li wrote:
>> On Thu, Jul 11, 2019 at 10:38 AM Becket Qin <[hidden email]> wrote:
>>
>>> Thanks everyone for all the comments and feedback. Please see the replies
>>> below:
>>>
>>> --------------------------------
>>> Re: Konstantin
>>>
>>>> * 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.
>>>
>>> Good point. Just added the entry.
>>>
>>> -------------------------------
>>> Re: Konstantin
>>>
>>>> * 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.
>>>
>>> & Re: Till
>>>
>>>> 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.
>>>
>>> I am with Robert and Aljoscha on this.
>>>
>>> I completely understand the concern here. TBH, in Kafka occasionally
>>> trivial patches from committers are still merged without following the
>>> cross-review requirement, but it is rare. That said, I still think an
>>> additional committer's review makes sense due to the following reasons:
>>> 1. The bottom line here is that we need to make sure every patch is
>>> reviewed with a high quality. This is a little difficult to guarantee if
>>> the review comes from a contributor for many reasons. In some cases, a
>>> contributor may not have enough knowledge about the project to make a good
>>> judgement. Also sometimes the contributors are more eagerly to get a
>>> particular issue fixed, so they are willing to lower the review bar.
>>> 2. One byproduct of such cross review among committers, which I personally
>>> feel useful, is that it helps gradually form consistent design principles
>>> and code style. This is because the committers will know how the other
>>> committers are writing code and learn from each other. So they tend to
>>> reach some tacit understanding on how things should be done in general.
>>>
>>> Another way to think about this is to consider the following two scenarios:
>>> 1. Reviewing a committer's patch takes a lot of iterations. Then the patch
>>> needs to be reviewed even if it takes time because there are things
>>> actually needs to be clarified / changed.
>>> 2. Reviewing a committer's patch is very smooth and quick, so the patch is
>>> merged soon. Then reviewing such a patch does not take much time.
>>>
>>> Letting another committer review the patch from a committer falls either in
>>> case 1 or case 2. The best option here is to review the patch because
>>> If it is case 1, the patch actually needs to be reviewed.
>>> If it is case 2, the review should not take much time anyways.
>>>
>>> In the contrast, we will risk encounter case 1 if we skip the cross-review.
>>>
>>> ------------------------
>>> Re: Robert
>>>
>>> I replied to your comments in the wiki and made the following modifications
>>> to resolve some of your comments:
>>> 1. Added a release manager role section.
>>> 2. changed the name of "lazy consensus" to "consensus" to align with
>>> general definition of Apache glossary and other projects.
>>> 3. review board  -> pull request
>>>
>>> -------------------------
>>> Re: Chesnay
>>>
>>> The emeritus stuff seems like unnecessary noise.
>>> As Till mentioned, this is to make sure 2/3 majority is still feasible in
>>> practice.
>>>
>>> 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.
>>> That is a good suggestion. I am not familiar enough with the current Flink
>>> convention. Will you help on this? I saw you commented on some part in the
>>> wiki. Are those complete?
>>>
>>> --------------------------
>>>  Re: Aljoscha
>>>
>>> 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.
>>> Ha, you got me on this. The first version of the draft was almost identical
>>> to Kafka. But Robert has already caught a few inconsistent places. So it
>>> might still worth going through it to make sure we truly agree on them.
>>> Otherwise we may end up modifying them shortly after adoption.
>>>
>>>
>>> Thanks again folks, for all the valuable feedback. These are great
>>> discussion.
>>>
>>> Jiangjie (Becket) Qin
>>>
>>> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha Krettek <[hidden email]>
>>> wrote:
>>>
>>>> Big +1
>>>>
>>>> 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.
>>>>
>>>> Aljoscha
>>>>
>>>>> 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
>>>>>>>>
>>>>>>>> [phone]
>>>>>>>>
>>>>>>>>
>>>>>>>> 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
>>>>>>>>
>>>>>>
>>>>
>

[Becket Qin]

Hi Chesnay,

We could do that. This might actually help unblock other things such as
META-FLIP discussion quicker. Will you or someone familiar enough with the
current state to write it down?
If we are going to have an itemized discussion, I think the parts need
immediate attention are:
1. Vote types (maybe just the one type for FLIP)
2. Which vote type should be for a FLIP.
3. Who has binding votes for a FLIP.

After these are clarified, we can conclude the FLIP-META discussion to fix
the broken FLIP process.
The Committer / PMC related discussions may not be that urgent as the
current convention, although not clearly defined, seems working fine.

Does that make sense?


Re Piotr:

Thanks for sharing your thoughts.

I’m missing this stated somewhere clearly. If we are stating that a single
> committers +1 is good enough for code review, with 0 hours delay (de facto
> the current state), we should also write down that this is subject to the
> best judgement of the committer to respect the components expertise and
> ongoing development plans (also the de facto current state).

Adding the statement would help clarify the intention, but it may be a
little difficult to enforce and follow...

Minimum length of 3 days for FLIP I think currently might be
> problematic/too quick and can lead to problems if respected to the letter.
> Again I think it depends highly on whether the committers with highest
> expertise in the affected components managed to respond or not.
>
The vote requires a minimum length of 3 days, but it could last longer in
order to collect enough binding votes. In most cases, only the committers
with enough expertise / interest would vote on the FLIP.

Thanks,

Jiangjie (Becket) Qin


On Fri, Jul 12, 2019 at 5:07 PM Piotr Nowojski <[hidden email]> wrote:

> Hi,
>
> Thanks for the proposal. Generally speaking +1 from my side to the general
> idea and most of the content. I also see merit to the Chesney's proposal to
> start from the current state. I think either would be fine for me.
>
> Couple of comments:
>
> 1.
>
> I also think that requiring +1 from another committer would slow down and
> put even more strain on the current reviewing bottleneck that we are
> having. Even if the change clear and simple, context switch cost is quite
> high, and that’s just one less PR that the second “cross” committer could
> have reviewed somewhere else in that time. Besides, current setup that we
> have (with no cross +1 from another committer required) works quite well
> and I do not feel that’s causing troubles. On the other hand reviewing
> bottleneck is.
>
> 2.
>
> > I think a committer should know when to ask another committer for
> feedback or not.
>
> I’m missing this stated somewhere clearly. If we are stating that a single
> committers +1 is good enough for code review, with 0 hours delay (de facto
> the current state), we should also write down that this is subject to the
> best judgement of the committer to respect the components expertise and
> ongoing development plans (also the de facto current state).
>
> 3.
>
> Minimum length of 3 days for FLIP I think currently might be
> problematic/too quick and can lead to problems if respected to the letter.
> Again I think it depends highly on whether the committers with highest
> expertise in the affected components managed to respond or not.
>
> Piotrek
>
> > On 12 Jul 2019, at 09:42, Chesnay Schepler <[hidden email]> wrote:
> >
> > I'm wondering whether we shouldn't first write down Bylaws that reflect
> the current state, and then have separate discussions for individual
> amendments. My gut feeling is that this discussion will quickly become a
> chaotic mess with plenty points being discussed at once.
> >
> > On 11/07/2019 20:03, Bowen Li wrote:
> >> On Thu, Jul 11, 2019 at 10:38 AM Becket Qin <[hidden email]>
> wrote:
> >>
> >>> Thanks everyone for all the comments and feedback. Please see the
> replies
> >>> below:
> >>>
> >>> --------------------------------
> >>> Re: Konstantin
> >>>
> >>>> * 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.
> >>>
> >>> Good point. Just added the entry.
> >>>
> >>> -------------------------------
> >>> Re: Konstantin
> >>>
> >>>> * 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.
> >>>
> >>> & Re: Till
> >>>
> >>>> 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.
> >>>
> >>> I am with Robert and Aljoscha on this.
> >>>
> >>> I completely understand the concern here. TBH, in Kafka occasionally
> >>> trivial patches from committers are still merged without following the
> >>> cross-review requirement, but it is rare. That said, I still think an
> >>> additional committer's review makes sense due to the following reasons:
> >>> 1. The bottom line here is that we need to make sure every patch is
> >>> reviewed with a high quality. This is a little difficult to guarantee
> if
> >>> the review comes from a contributor for many reasons. In some cases, a
> >>> contributor may not have enough knowledge about the project to make a
> good
> >>> judgement. Also sometimes the contributors are more eagerly to get a
> >>> particular issue fixed, so they are willing to lower the review bar.
> >>> 2. One byproduct of such cross review among committers, which I
> personally
> >>> feel useful, is that it helps gradually form consistent design
> principles
> >>> and code style. This is because the committers will know how the other
> >>> committers are writing code and learn from each other. So they tend to
> >>> reach some tacit understanding on how things should be done in general.
> >>>
> >>> Another way to think about this is to consider the following two
> scenarios:
> >>> 1. Reviewing a committer's patch takes a lot of iterations. Then the
> patch
> >>> needs to be reviewed even if it takes time because there are things
> >>> actually needs to be clarified / changed.
> >>> 2. Reviewing a committer's patch is very smooth and quick, so the
> patch is
> >>> merged soon. Then reviewing such a patch does not take much time.
> >>>
> >>> Letting another committer review the patch from a committer falls
> either in
> >>> case 1 or case 2. The best option here is to review the patch because
> >>> If it is case 1, the patch actually needs to be reviewed.
> >>> If it is case 2, the review should not take much time anyways.
> >>>
> >>> In the contrast, we will risk encounter case 1 if we skip the
> cross-review.
> >>>
> >>> ------------------------
> >>> Re: Robert
> >>>
> >>> I replied to your comments in the wiki and made the following
> modifications
> >>> to resolve some of your comments:
> >>> 1. Added a release manager role section.
> >>> 2. changed the name of "lazy consensus" to "consensus" to align with
> >>> general definition of Apache glossary and other projects.
> >>> 3. review board  -> pull request
> >>>
> >>> -------------------------
> >>> Re: Chesnay
> >>>
> >>> The emeritus stuff seems like unnecessary noise.
> >>> As Till mentioned, this is to make sure 2/3 majority is still feasible
> in
> >>> practice.
> >>>
> >>> 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.
> >>> That is a good suggestion. I am not familiar enough with the current
> Flink
> >>> convention. Will you help on this? I saw you commented on some part in
> the
> >>> wiki. Are those complete?
> >>>
> >>> --------------------------
> >>>  Re: Aljoscha
> >>>
> >>> 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.
> >>> Ha, you got me on this. The first version of the draft was almost
> identical
> >>> to Kafka. But Robert has already caught a few inconsistent places. So
> it
> >>> might still worth going through it to make sure we truly agree on them.
> >>> Otherwise we may end up modifying them shortly after adoption.
> >>>
> >>>
> >>> Thanks again folks, for all the valuable feedback. These are great
> >>> discussion.
> >>>
> >>> Jiangjie (Becket) Qin
> >>>
> >>> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha Krettek <[hidden email]>
> >>> wrote:
> >>>
> >>>> Big +1
> >>>>
> >>>> 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.
> >>>>
> >>>> Aljoscha
> >>>>
> >>>>> 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
> >>>>>>>>
> >>>>>>>> [phone]
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>>
> >>>>>>
> >>>>
> >
>
>

[Aljoscha Krettek-2]

@Piotr regarding the 3 days voting on the FLIP. This is just about the voting, before that there needs to be the discussion thread. If three days have passed on a vote and there is consensus (i.e. 3 committers/PMCs have voted +1) that seems a high enough bar for me. So far, we have rarely see any FLIPs pass that formal bar.

According to the recent META-FLIP thread, we want to use "lazy majority" for the FLIP voting process. I think that should be changed from “consensus” in the proposed bylaws.

Regarding the current state: do we have a current state that we all agree on? I have the feeling that if we try to come up with something that reflects the common state, according to PMCs/commiters, that might take a very long time. In that case I think it’s better to adopt something that we all like, rather than trying to capture how we do it now.

Aljoscha

> On 12. Jul 2019, at 11:07, Piotr Nowojski <[hidden email]> wrote:
>
> Hi,
>
> Thanks for the proposal. Generally speaking +1 from my side to the general idea and most of the content. I also see merit to the Chesney's proposal to start from the current state. I think either would be fine for me.
>
> Couple of comments:
>
> 1.
>
> I also think that requiring +1 from another committer would slow down and put even more strain on the current reviewing bottleneck that we are having. Even if the change clear and simple, context switch cost is quite high, and that’s just one less PR that the second “cross” committer could have reviewed somewhere else in that time. Besides, current setup that we have (with no cross +1 from another committer required) works quite well and I do not feel that’s causing troubles. On the other hand reviewing bottleneck is.
>
> 2.
>
>> I think a committer should know when to ask another committer for feedback or not.
>
> I’m missing this stated somewhere clearly. If we are stating that a single committers +1 is good enough for code review, with 0 hours delay (de facto the current state), we should also write down that this is subject to the best judgement of the committer to respect the components expertise and ongoing development plans (also the de facto current state).
>
> 3.
>
> Minimum length of 3 days for FLIP I think currently might be problematic/too quick and can lead to problems if respected to the letter. Again I think it depends highly on whether the committers with highest expertise in the affected components managed to respond or not.
>
> Piotrek
>
>> On 12 Jul 2019, at 09:42, Chesnay Schepler <[hidden email]> wrote:
>>
>> I'm wondering whether we shouldn't first write down Bylaws that reflect the current state, and then have separate discussions for individual amendments. My gut feeling is that this discussion will quickly become a chaotic mess with plenty points being discussed at once.
>>
>> On 11/07/2019 20:03, Bowen Li wrote:
>>> On Thu, Jul 11, 2019 at 10:38 AM Becket Qin <[hidden email]> wrote:
>>>
>>>> Thanks everyone for all the comments and feedback. Please see the replies
>>>> below:
>>>>
>>>> --------------------------------
>>>> Re: Konstantin
>>>>
>>>>> * 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.
>>>>
>>>> Good point. Just added the entry.
>>>>
>>>> -------------------------------
>>>> Re: Konstantin
>>>>
>>>>> * 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.
>>>>
>>>> & Re: Till
>>>>
>>>>> 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.
>>>>
>>>> I am with Robert and Aljoscha on this.
>>>>
>>>> I completely understand the concern here. TBH, in Kafka occasionally
>>>> trivial patches from committers are still merged without following the
>>>> cross-review requirement, but it is rare. That said, I still think an
>>>> additional committer's review makes sense due to the following reasons:
>>>> 1. The bottom line here is that we need to make sure every patch is
>>>> reviewed with a high quality. This is a little difficult to guarantee if
>>>> the review comes from a contributor for many reasons. In some cases, a
>>>> contributor may not have enough knowledge about the project to make a good
>>>> judgement. Also sometimes the contributors are more eagerly to get a
>>>> particular issue fixed, so they are willing to lower the review bar.
>>>> 2. One byproduct of such cross review among committers, which I personally
>>>> feel useful, is that it helps gradually form consistent design principles
>>>> and code style. This is because the committers will know how the other
>>>> committers are writing code and learn from each other. So they tend to
>>>> reach some tacit understanding on how things should be done in general.
>>>>
>>>> Another way to think about this is to consider the following two scenarios:
>>>> 1. Reviewing a committer's patch takes a lot of iterations. Then the patch
>>>> needs to be reviewed even if it takes time because there are things
>>>> actually needs to be clarified / changed.
>>>> 2. Reviewing a committer's patch is very smooth and quick, so the patch is
>>>> merged soon. Then reviewing such a patch does not take much time.
>>>>
>>>> Letting another committer review the patch from a committer falls either in
>>>> case 1 or case 2. The best option here is to review the patch because
>>>> If it is case 1, the patch actually needs to be reviewed.
>>>> If it is case 2, the review should not take much time anyways.
>>>>
>>>> In the contrast, we will risk encounter case 1 if we skip the cross-review.
>>>>
>>>> ------------------------
>>>> Re: Robert
>>>>
>>>> I replied to your comments in the wiki and made the following modifications
>>>> to resolve some of your comments:
>>>> 1. Added a release manager role section.
>>>> 2. changed the name of "lazy consensus" to "consensus" to align with
>>>> general definition of Apache glossary and other projects.
>>>> 3. review board  -> pull request
>>>>
>>>> -------------------------
>>>> Re: Chesnay
>>>>
>>>> The emeritus stuff seems like unnecessary noise.
>>>> As Till mentioned, this is to make sure 2/3 majority is still feasible in
>>>> practice.
>>>>
>>>> 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.
>>>> That is a good suggestion. I am not familiar enough with the current Flink
>>>> convention. Will you help on this? I saw you commented on some part in the
>>>> wiki. Are those complete?
>>>>
>>>> --------------------------
>>>> Re: Aljoscha
>>>>
>>>> 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.
>>>> Ha, you got me on this. The first version of the draft was almost identical
>>>> to Kafka. But Robert has already caught a few inconsistent places. So it
>>>> might still worth going through it to make sure we truly agree on them.
>>>> Otherwise we may end up modifying them shortly after adoption.
>>>>
>>>>
>>>> Thanks again folks, for all the valuable feedback. These are great
>>>> discussion.
>>>>
>>>> Jiangjie (Becket) Qin
>>>>
>>>> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha Krettek <[hidden email]>
>>>> wrote:
>>>>
>>>>> Big +1
>>>>>
>>>>> 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.
>>>>>
>>>>> Aljoscha
>>>>>
>>>>>> 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
>>>>>>>>>
>>>>>>>>> [phone]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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
>>>>>>>>>
>>>>>>>
>>>>>
>>
>

[Piotr Nowojski-3]

Hi Aljoscha and Becket

Right, 3 days for FLIP voting is fine I think.

>> I’m missing this stated somewhere clearly. If we are stating that a single
>> committers +1 is good enough for code review, with 0 hours delay (de facto
>> the current state), we should also write down that this is subject to the
>> best judgement of the committer to respect the components expertise and
>> ongoing development plans (also the de facto current state).
>
> Adding the statement would help clarify the intention, but it may be a
> little difficult to enforce and follow..

I would be fine with that, it’s a soft/vague rule anyway, intended to be used with your “best judgemenet". I would like to just avoid a situation when someone violates current uncodified state and refers to the bylaws which are saying merging with any committer +1 is always fine (like mine +1 for flink-python or flink-ml).

Piotrek

> On 12 Jul 2019, at 11:29, Aljoscha Krettek <[hidden email]> wrote:
>
> @Piotr regarding the 3 days voting on the FLIP. This is just about the voting, before that there needs to be the discussion thread. If three days have passed on a vote and there is consensus (i.e. 3 committers/PMCs have voted +1) that seems a high enough bar for me. So far, we have rarely see any FLIPs pass that formal bar.
>
> According to the recent META-FLIP thread, we want to use "lazy majority" for the FLIP voting process. I think that should be changed from “consensus” in the proposed bylaws.
>
> Regarding the current state: do we have a current state that we all agree on? I have the feeling that if we try to come up with something that reflects the common state, according to PMCs/commiters, that might take a very long time. In that case I think it’s better to adopt something that we all like, rather than trying to capture how we do it now.
>
> Aljoscha
>
>> On 12. Jul 2019, at 11:07, Piotr Nowojski <[hidden email]> wrote:
>>
>> Hi,
>>
>> Thanks for the proposal. Generally speaking +1 from my side to the general idea and most of the content. I also see merit to the Chesney's proposal to start from the current state. I think either would be fine for me.
>>
>> Couple of comments:
>>
>> 1.
>>
>> I also think that requiring +1 from another committer would slow down and put even more strain on the current reviewing bottleneck that we are having. Even if the change clear and simple, context switch cost is quite high, and that’s just one less PR that the second “cross” committer could have reviewed somewhere else in that time. Besides, current setup that we have (with no cross +1 from another committer required) works quite well and I do not feel that’s causing troubles. On the other hand reviewing bottleneck is.
>>
>> 2.
>>
>>> I think a committer should know when to ask another committer for feedback or not.
>>
>> I’m missing this stated somewhere clearly. If we are stating that a single committers +1 is good enough for code review, with 0 hours delay (de facto the current state), we should also write down that this is subject to the best judgement of the committer to respect the components expertise and ongoing development plans (also the de facto current state).
>>
>> 3.
>>
>> Minimum length of 3 days for FLIP I think currently might be problematic/too quick and can lead to problems if respected to the letter. Again I think it depends highly on whether the committers with highest expertise in the affected components managed to respond or not.
>>
>> Piotrek
>>
>>> On 12 Jul 2019, at 09:42, Chesnay Schepler <[hidden email]> wrote:
>>>
>>> I'm wondering whether we shouldn't first write down Bylaws that reflect the current state, and then have separate discussions for individual amendments. My gut feeling is that this discussion will quickly become a chaotic mess with plenty points being discussed at once.
>>>
>>> On 11/07/2019 20:03, Bowen Li wrote:
>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket Qin <[hidden email]> wrote:
>>>>
>>>>> Thanks everyone for all the comments and feedback. Please see the replies
>>>>> below:
>>>>>
>>>>> --------------------------------
>>>>> Re: Konstantin
>>>>>
>>>>>> * 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.
>>>>>
>>>>> Good point. Just added the entry.
>>>>>
>>>>> -------------------------------
>>>>> Re: Konstantin
>>>>>
>>>>>> * 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.
>>>>>
>>>>> & Re: Till
>>>>>
>>>>>> 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.
>>>>>
>>>>> I am with Robert and Aljoscha on this.
>>>>>
>>>>> I completely understand the concern here. TBH, in Kafka occasionally
>>>>> trivial patches from committers are still merged without following the
>>>>> cross-review requirement, but it is rare. That said, I still think an
>>>>> additional committer's review makes sense due to the following reasons:
>>>>> 1. The bottom line here is that we need to make sure every patch is
>>>>> reviewed with a high quality. This is a little difficult to guarantee if
>>>>> the review comes from a contributor for many reasons. In some cases, a
>>>>> contributor may not have enough knowledge about the project to make a good
>>>>> judgement. Also sometimes the contributors are more eagerly to get a
>>>>> particular issue fixed, so they are willing to lower the review bar.
>>>>> 2. One byproduct of such cross review among committers, which I personally
>>>>> feel useful, is that it helps gradually form consistent design principles
>>>>> and code style. This is because the committers will know how the other
>>>>> committers are writing code and learn from each other. So they tend to
>>>>> reach some tacit understanding on how things should be done in general.
>>>>>
>>>>> Another way to think about this is to consider the following two scenarios:
>>>>> 1. Reviewing a committer's patch takes a lot of iterations. Then the patch
>>>>> needs to be reviewed even if it takes time because there are things
>>>>> actually needs to be clarified / changed.
>>>>> 2. Reviewing a committer's patch is very smooth and quick, so the patch is
>>>>> merged soon. Then reviewing such a patch does not take much time.
>>>>>
>>>>> Letting another committer review the patch from a committer falls either in
>>>>> case 1 or case 2. The best option here is to review the patch because
>>>>> If it is case 1, the patch actually needs to be reviewed.
>>>>> If it is case 2, the review should not take much time anyways.
>>>>>
>>>>> In the contrast, we will risk encounter case 1 if we skip the cross-review.
>>>>>
>>>>> ------------------------
>>>>> Re: Robert
>>>>>
>>>>> I replied to your comments in the wiki and made the following modifications
>>>>> to resolve some of your comments:
>>>>> 1. Added a release manager role section.
>>>>> 2. changed the name of "lazy consensus" to "consensus" to align with
>>>>> general definition of Apache glossary and other projects.
>>>>> 3. review board  -> pull request
>>>>>
>>>>> -------------------------
>>>>> Re: Chesnay
>>>>>
>>>>> The emeritus stuff seems like unnecessary noise.
>>>>> As Till mentioned, this is to make sure 2/3 majority is still feasible in
>>>>> practice.
>>>>>
>>>>> 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.
>>>>> That is a good suggestion. I am not familiar enough with the current Flink
>>>>> convention. Will you help on this? I saw you commented on some part in the
>>>>> wiki. Are those complete?
>>>>>
>>>>> --------------------------
>>>>> Re: Aljoscha
>>>>>
>>>>> 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.
>>>>> Ha, you got me on this. The first version of the draft was almost identical
>>>>> to Kafka. But Robert has already caught a few inconsistent places. So it
>>>>> might still worth going through it to make sure we truly agree on them.
>>>>> Otherwise we may end up modifying them shortly after adoption.
>>>>>
>>>>>
>>>>> Thanks again folks, for all the valuable feedback. These are great
>>>>> discussion.
>>>>>
>>>>> Jiangjie (Becket) Qin
>>>>>
>>>>> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha Krettek <[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Big +1
>>>>>>
>>>>>> 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.
>>>>>>
>>>>>> Aljoscha
>>>>>>
>>>>>>> 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
>>>>>>>>>>
>>>>>>>>>> [phone]
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> 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
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>
>>
>

[dwysakowicz]

Hi all,

Sorry for joining late. I just wanted to say that I really like the
proposed bylaws!

One comment, I also have the same concerns as expressed by few people
before that the "committer +1" on code change might be hard to achieve
currently. On the other hand I would say this would be beneficial for
the quality/uniformity of our codebase and knowledge sharing.

I was just wondering what should be the next step for this? I think it
would make sense to already use those bylaws and put them to PMC vote.

Best,

Dawid

On 12/07/2019 13:35, Piotr Nowojski wrote:

> Hi Aljoscha and Becket
>
> Right, 3 days for FLIP voting is fine I think.
>
>>> I’m missing this stated somewhere clearly. If we are stating that a single
>>> committers +1 is good enough for code review, with 0 hours delay (de facto
>>> the current state), we should also write down that this is subject to the
>>> best judgement of the committer to respect the components expertise and
>>> ongoing development plans (also the de facto current state).
>> Adding the statement would help clarify the intention, but it may be a
>> little difficult to enforce and follow..
> I would be fine with that, it’s a soft/vague rule anyway, intended to be used with your “best judgemenet". I would like to just avoid a situation when someone violates current uncodified state and refers to the bylaws which are saying merging with any committer +1 is always fine (like mine +1 for flink-python or flink-ml).
>
> Piotrek
>
>> On 12 Jul 2019, at 11:29, Aljoscha Krettek <[hidden email]> wrote:
>>
>> @Piotr regarding the 3 days voting on the FLIP. This is just about the voting, before that there needs to be the discussion thread. If three days have passed on a vote and there is consensus (i.e. 3 committers/PMCs have voted +1) that seems a high enough bar for me. So far, we have rarely see any FLIPs pass that formal bar.
>>
>> According to the recent META-FLIP thread, we want to use "lazy majority" for the FLIP voting process. I think that should be changed from “consensus” in the proposed bylaws.
>>
>> Regarding the current state: do we have a current state that we all agree on? I have the feeling that if we try to come up with something that reflects the common state, according to PMCs/commiters, that might take a very long time. In that case I think it’s better to adopt something that we all like, rather than trying to capture how we do it now.
>>
>> Aljoscha
>>
>>> On 12. Jul 2019, at 11:07, Piotr Nowojski <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>> Thanks for the proposal. Generally speaking +1 from my side to the general idea and most of the content. I also see merit to the Chesney's proposal to start from the current state. I think either would be fine for me.
>>>
>>> Couple of comments:
>>>
>>> 1.
>>>
>>> I also think that requiring +1 from another committer would slow down and put even more strain on the current reviewing bottleneck that we are having. Even if the change clear and simple, context switch cost is quite high, and that’s just one less PR that the second “cross” committer could have reviewed somewhere else in that time. Besides, current setup that we have (with no cross +1 from another committer required) works quite well and I do not feel that’s causing troubles. On the other hand reviewing bottleneck is.
>>>
>>> 2.
>>>
>>>> I think a committer should know when to ask another committer for feedback or not.
>>> I’m missing this stated somewhere clearly. If we are stating that a single committers +1 is good enough for code review, with 0 hours delay (de facto the current state), we should also write down that this is subject to the best judgement of the committer to respect the components expertise and ongoing development plans (also the de facto current state).
>>>
>>> 3.
>>>
>>> Minimum length of 3 days for FLIP I think currently might be problematic/too quick and can lead to problems if respected to the letter. Again I think it depends highly on whether the committers with highest expertise in the affected components managed to respond or not.
>>>
>>> Piotrek
>>>
>>>> On 12 Jul 2019, at 09:42, Chesnay Schepler <[hidden email]> wrote:
>>>>
>>>> I'm wondering whether we shouldn't first write down Bylaws that reflect the current state, and then have separate discussions for individual amendments. My gut feeling is that this discussion will quickly become a chaotic mess with plenty points being discussed at once.
>>>>
>>>> On 11/07/2019 20:03, Bowen Li wrote:
>>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket Qin <[hidden email]> wrote:
>>>>>
>>>>>> Thanks everyone for all the comments and feedback. Please see the replies
>>>>>> below:
>>>>>>
>>>>>> --------------------------------
>>>>>> Re: Konstantin
>>>>>>
>>>>>>> * 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.
>>>>>> Good point. Just added the entry.
>>>>>>
>>>>>> -------------------------------
>>>>>> Re: Konstantin
>>>>>>
>>>>>>> * 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.
>>>>>> & Re: Till
>>>>>>
>>>>>>> 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.
>>>>>> I am with Robert and Aljoscha on this.
>>>>>>
>>>>>> I completely understand the concern here. TBH, in Kafka occasionally
>>>>>> trivial patches from committers are still merged without following the
>>>>>> cross-review requirement, but it is rare. That said, I still think an
>>>>>> additional committer's review makes sense due to the following reasons:
>>>>>> 1. The bottom line here is that we need to make sure every patch is
>>>>>> reviewed with a high quality. This is a little difficult to guarantee if
>>>>>> the review comes from a contributor for many reasons. In some cases, a
>>>>>> contributor may not have enough knowledge about the project to make a good
>>>>>> judgement. Also sometimes the contributors are more eagerly to get a
>>>>>> particular issue fixed, so they are willing to lower the review bar.
>>>>>> 2. One byproduct of such cross review among committers, which I personally
>>>>>> feel useful, is that it helps gradually form consistent design principles
>>>>>> and code style. This is because the committers will know how the other
>>>>>> committers are writing code and learn from each other. So they tend to
>>>>>> reach some tacit understanding on how things should be done in general.
>>>>>>
>>>>>> Another way to think about this is to consider the following two scenarios:
>>>>>> 1. Reviewing a committer's patch takes a lot of iterations. Then the patch
>>>>>> needs to be reviewed even if it takes time because there are things
>>>>>> actually needs to be clarified / changed.
>>>>>> 2. Reviewing a committer's patch is very smooth and quick, so the patch is
>>>>>> merged soon. Then reviewing such a patch does not take much time.
>>>>>>
>>>>>> Letting another committer review the patch from a committer falls either in
>>>>>> case 1 or case 2. The best option here is to review the patch because
>>>>>> If it is case 1, the patch actually needs to be reviewed.
>>>>>> If it is case 2, the review should not take much time anyways.
>>>>>>
>>>>>> In the contrast, we will risk encounter case 1 if we skip the cross-review.
>>>>>>
>>>>>> ------------------------
>>>>>> Re: Robert
>>>>>>
>>>>>> I replied to your comments in the wiki and made the following modifications
>>>>>> to resolve some of your comments:
>>>>>> 1. Added a release manager role section.
>>>>>> 2. changed the name of "lazy consensus" to "consensus" to align with
>>>>>> general definition of Apache glossary and other projects.
>>>>>> 3. review board  -> pull request
>>>>>>
>>>>>> -------------------------
>>>>>> Re: Chesnay
>>>>>>
>>>>>> The emeritus stuff seems like unnecessary noise.
>>>>>> As Till mentioned, this is to make sure 2/3 majority is still feasible in
>>>>>> practice.
>>>>>>
>>>>>> 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.
>>>>>> That is a good suggestion. I am not familiar enough with the current Flink
>>>>>> convention. Will you help on this? I saw you commented on some part in the
>>>>>> wiki. Are those complete?
>>>>>>
>>>>>> --------------------------
>>>>>> Re: Aljoscha
>>>>>>
>>>>>> 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.
>>>>>> Ha, you got me on this. The first version of the draft was almost identical
>>>>>> to Kafka. But Robert has already caught a few inconsistent places. So it
>>>>>> might still worth going through it to make sure we truly agree on them.
>>>>>> Otherwise we may end up modifying them shortly after adoption.
>>>>>>
>>>>>>
>>>>>> Thanks again folks, for all the valuable feedback. These are great
>>>>>> discussion.
>>>>>>
>>>>>> Jiangjie (Becket) Qin
>>>>>>
>>>>>> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha Krettek <[hidden email]>
>>>>>> wrote:
>>>>>>
>>>>>>> Big +1
>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> Aljoscha
>>>>>>>
>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>> [phone]
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> 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
>>>>>>>>>>>

[jincheng sun]

Hi Becket,

Thanks for the proposal.

Regarding the vote of FLIP, preferably at least includes a PMC vote.
Because FLIP is usually a big change or affects the user's interface
changes. What do you think? (I leave the comment in the wiki.)

Best,
Jincheng

Dawid Wysakowicz <[hidden email]> 于2019年7月17日周三 下午9:12写道：

> Hi all,
>
> Sorry for joining late. I just wanted to say that I really like the
> proposed bylaws!
>
> One comment, I also have the same concerns as expressed by few people
> before that the "committer +1" on code change might be hard to achieve
> currently. On the other hand I would say this would be beneficial for
> the quality/uniformity of our codebase and knowledge sharing.
>
> I was just wondering what should be the next step for this? I think it
> would make sense to already use those bylaws and put them to PMC vote.
>
> Best,
>
> Dawid
>
> On 12/07/2019 13:35, Piotr Nowojski wrote:
> > Hi Aljoscha and Becket
> >
> > Right, 3 days for FLIP voting is fine I think.
> >
> >>> I’m missing this stated somewhere clearly. If we are stating that a
> single
> >>> committers +1 is good enough for code review, with 0 hours delay (de
> facto
> >>> the current state), we should also write down that this is subject to
> the
> >>> best judgement of the committer to respect the components expertise and
> >>> ongoing development plans (also the de facto current state).
> >> Adding the statement would help clarify the intention, but it may be a
> >> little difficult to enforce and follow..
> > I would be fine with that, it’s a soft/vague rule anyway, intended to be
> used with your “best judgemenet". I would like to just avoid a situation
> when someone violates current uncodified state and refers to the bylaws
> which are saying merging with any committer +1 is always fine (like mine +1
> for flink-python or flink-ml).
> >
> > Piotrek
> >
> >> On 12 Jul 2019, at 11:29, Aljoscha Krettek <[hidden email]> wrote:
> >>
> >> @Piotr regarding the 3 days voting on the FLIP. This is just about the
> voting, before that there needs to be the discussion thread. If three days
> have passed on a vote and there is consensus (i.e. 3 committers/PMCs have
> voted +1) that seems a high enough bar for me. So far, we have rarely see
> any FLIPs pass that formal bar.
> >>
> >> According to the recent META-FLIP thread, we want to use "lazy
> majority" for the FLIP voting process. I think that should be changed from
> “consensus” in the proposed bylaws.
> >>
> >> Regarding the current state: do we have a current state that we all
> agree on? I have the feeling that if we try to come up with something that
> reflects the common state, according to PMCs/commiters, that might take a
> very long time. In that case I think it’s better to adopt something that we
> all like, rather than trying to capture how we do it now.
> >>
> >> Aljoscha
> >>
> >>> On 12. Jul 2019, at 11:07, Piotr Nowojski <[hidden email]> wrote:
> >>>
> >>> Hi,
> >>>
> >>> Thanks for the proposal. Generally speaking +1 from my side to the
> general idea and most of the content. I also see merit to the Chesney's
> proposal to start from the current state. I think either would be fine for
> me.
> >>>
> >>> Couple of comments:
> >>>
> >>> 1.
> >>>
> >>> I also think that requiring +1 from another committer would slow down
> and put even more strain on the current reviewing bottleneck that we are
> having. Even if the change clear and simple, context switch cost is quite
> high, and that’s just one less PR that the second “cross” committer could
> have reviewed somewhere else in that time. Besides, current setup that we
> have (with no cross +1 from another committer required) works quite well
> and I do not feel that’s causing troubles. On the other hand reviewing
> bottleneck is.
> >>>
> >>> 2.
> >>>
> >>>> I think a committer should know when to ask another committer for
> feedback or not.
> >>> I’m missing this stated somewhere clearly. If we are stating that a
> single committers +1 is good enough for code review, with 0 hours delay (de
> facto the current state), we should also write down that this is subject to
> the best judgement of the committer to respect the components expertise and
> ongoing development plans (also the de facto current state).
> >>>
> >>> 3.
> >>>
> >>> Minimum length of 3 days for FLIP I think currently might be
> problematic/too quick and can lead to problems if respected to the letter.
> Again I think it depends highly on whether the committers with highest
> expertise in the affected components managed to respond or not.
> >>>
> >>> Piotrek
> >>>
> >>>> On 12 Jul 2019, at 09:42, Chesnay Schepler <[hidden email]>
> wrote:
> >>>>
> >>>> I'm wondering whether we shouldn't first write down Bylaws that
> reflect the current state, and then have separate discussions for
> individual amendments. My gut feeling is that this discussion will quickly
> become a chaotic mess with plenty points being discussed at once.
> >>>>
> >>>> On 11/07/2019 20:03, Bowen Li wrote:
> >>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket Qin <[hidden email]>
> wrote:
> >>>>>
> >>>>>> Thanks everyone for all the comments and feedback. Please see the
> replies
> >>>>>> below:
> >>>>>>
> >>>>>> --------------------------------
> >>>>>> Re: Konstantin
> >>>>>>
> >>>>>>> * 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.
> >>>>>> Good point. Just added the entry.
> >>>>>>
> >>>>>> -------------------------------
> >>>>>> Re: Konstantin
> >>>>>>
> >>>>>>> * 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.
> >>>>>> & Re: Till
> >>>>>>
> >>>>>>> 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.
> >>>>>> I am with Robert and Aljoscha on this.
> >>>>>>
> >>>>>> I completely understand the concern here. TBH, in Kafka occasionally
> >>>>>> trivial patches from committers are still merged without following
> the
> >>>>>> cross-review requirement, but it is rare. That said, I still think
> an
> >>>>>> additional committer's review makes sense due to the following
> reasons:
> >>>>>> 1. The bottom line here is that we need to make sure every patch is
> >>>>>> reviewed with a high quality. This is a little difficult to
> guarantee if
> >>>>>> the review comes from a contributor for many reasons. In some
> cases, a
> >>>>>> contributor may not have enough knowledge about the project to make
> a good
> >>>>>> judgement. Also sometimes the contributors are more eagerly to get a
> >>>>>> particular issue fixed, so they are willing to lower the review bar.
> >>>>>> 2. One byproduct of such cross review among committers, which I
> personally
> >>>>>> feel useful, is that it helps gradually form consistent design
> principles
> >>>>>> and code style. This is because the committers will know how the
> other
> >>>>>> committers are writing code and learn from each other. So they tend
> to
> >>>>>> reach some tacit understanding on how things should be done in
> general.
> >>>>>>
> >>>>>> Another way to think about this is to consider the following two
> scenarios:
> >>>>>> 1. Reviewing a committer's patch takes a lot of iterations. Then
> the patch
> >>>>>> needs to be reviewed even if it takes time because there are things
> >>>>>> actually needs to be clarified / changed.
> >>>>>> 2. Reviewing a committer's patch is very smooth and quick, so the
> patch is
> >>>>>> merged soon. Then reviewing such a patch does not take much time.
> >>>>>>
> >>>>>> Letting another committer review the patch from a committer falls
> either in
> >>>>>> case 1 or case 2. The best option here is to review the patch
> because
> >>>>>> If it is case 1, the patch actually needs to be reviewed.
> >>>>>> If it is case 2, the review should not take much time anyways.
> >>>>>>
> >>>>>> In the contrast, we will risk encounter case 1 if we skip the
> cross-review.
> >>>>>>
> >>>>>> ------------------------
> >>>>>> Re: Robert
> >>>>>>
> >>>>>> I replied to your comments in the wiki and made the following
> modifications
> >>>>>> to resolve some of your comments:
> >>>>>> 1. Added a release manager role section.
> >>>>>> 2. changed the name of "lazy consensus" to "consensus" to align with
> >>>>>> general definition of Apache glossary and other projects.
> >>>>>> 3. review board  -> pull request
> >>>>>>
> >>>>>> -------------------------
> >>>>>> Re: Chesnay
> >>>>>>
> >>>>>> The emeritus stuff seems like unnecessary noise.
> >>>>>> As Till mentioned, this is to make sure 2/3 majority is still
> feasible in
> >>>>>> practice.
> >>>>>>
> >>>>>> 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.
> >>>>>> That is a good suggestion. I am not familiar enough with the
> current Flink
> >>>>>> convention. Will you help on this? I saw you commented on some part
> in the
> >>>>>> wiki. Are those complete?
> >>>>>>
> >>>>>> --------------------------
> >>>>>> Re: Aljoscha
> >>>>>>
> >>>>>> 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.
> >>>>>> Ha, you got me on this. The first version of the draft was almost
> identical
> >>>>>> to Kafka. But Robert has already caught a few inconsistent places.
> So it
> >>>>>> might still worth going through it to make sure we truly agree on
> them.
> >>>>>> Otherwise we may end up modifying them shortly after adoption.
> >>>>>>
> >>>>>>
> >>>>>> Thanks again folks, for all the valuable feedback. These are great
> >>>>>> discussion.
> >>>>>>
> >>>>>> Jiangjie (Becket) Qin
> >>>>>>
> >>>>>> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha Krettek <
> [hidden email]>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Big +1
> >>>>>>>
> >>>>>>> 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.
> >>>>>>>
> >>>>>>> Aljoscha
> >>>>>>>
> >>>>>>>> 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
> >>>>>>>>>>>
> >>>>>>>>>>> [phone]
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> 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
> >>>>>>>>>>>
>
>

[Robert Metzger]

Hi all,
I agree with Aljoscha that trying to reflect the current status in the
bylaws, and then implementing changes one by one is a very involved task.
Unless there's somebody who's really eager to drive this, I would stick to
Becket's initiative to come up with Bylaws for Flink, even if this means
some changes.

The cross-review requirement is the last big open point in this discussion.
It seems that a there is a slight tendency in the discussion that this is
not feasible given the current pull request review situation.
For the sake of bringing this discussion to a conclusion, I'm fine with
leaving this requirement out. As we are currently adding more committers to
the project, we might be able to revisit this discussion in 3 - 6 months.


On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <[hidden email]>
wrote:

> Hi Becket,
>
> Thanks for the proposal.
>
> Regarding the vote of FLIP, preferably at least includes a PMC vote.
> Because FLIP is usually a big change or affects the user's interface
> changes. What do you think? (I leave the comment in the wiki.)
>
> Best,
> Jincheng
>
> Dawid Wysakowicz <[hidden email]> 于2019年7月17日周三 下午9:12写道：
>
> > Hi all,
> >
> > Sorry for joining late. I just wanted to say that I really like the
> > proposed bylaws!
> >
> > One comment, I also have the same concerns as expressed by few people
> > before that the "committer +1" on code change might be hard to achieve
> > currently. On the other hand I would say this would be beneficial for
> > the quality/uniformity of our codebase and knowledge sharing.
> >
> > I was just wondering what should be the next step for this? I think it
> > would make sense to already use those bylaws and put them to PMC vote.
> >
> > Best,
> >
> > Dawid
> >
> > On 12/07/2019 13:35, Piotr Nowojski wrote:
> > > Hi Aljoscha and Becket
> > >
> > > Right, 3 days for FLIP voting is fine I think.
> > >
> > >>> I’m missing this stated somewhere clearly. If we are stating that a
> > single
> > >>> committers +1 is good enough for code review, with 0 hours delay (de
> > facto
> > >>> the current state), we should also write down that this is subject to
> > the
> > >>> best judgement of the committer to respect the components expertise
> and
> > >>> ongoing development plans (also the de facto current state).
> > >> Adding the statement would help clarify the intention, but it may be a
> > >> little difficult to enforce and follow..
> > > I would be fine with that, it’s a soft/vague rule anyway, intended to
> be
> > used with your “best judgemenet". I would like to just avoid a situation
> > when someone violates current uncodified state and refers to the bylaws
> > which are saying merging with any committer +1 is always fine (like mine
> +1
> > for flink-python or flink-ml).
> > >
> > > Piotrek
> > >
> > >> On 12 Jul 2019, at 11:29, Aljoscha Krettek <[hidden email]>
> wrote:
> > >>
> > >> @Piotr regarding the 3 days voting on the FLIP. This is just about the
> > voting, before that there needs to be the discussion thread. If three
> days
> > have passed on a vote and there is consensus (i.e. 3 committers/PMCs have
> > voted +1) that seems a high enough bar for me. So far, we have rarely see
> > any FLIPs pass that formal bar.
> > >>
> > >> According to the recent META-FLIP thread, we want to use "lazy
> > majority" for the FLIP voting process. I think that should be changed
> from
> > “consensus” in the proposed bylaws.
> > >>
> > >> Regarding the current state: do we have a current state that we all
> > agree on? I have the feeling that if we try to come up with something
> that
> > reflects the common state, according to PMCs/commiters, that might take a
> > very long time. In that case I think it’s better to adopt something that
> we
> > all like, rather than trying to capture how we do it now.
> > >>
> > >> Aljoscha
> > >>
> > >>> On 12. Jul 2019, at 11:07, Piotr Nowojski <[hidden email]>
> wrote:
> > >>>
> > >>> Hi,
> > >>>
> > >>> Thanks for the proposal. Generally speaking +1 from my side to the
> > general idea and most of the content. I also see merit to the Chesney's
> > proposal to start from the current state. I think either would be fine
> for
> > me.
> > >>>
> > >>> Couple of comments:
> > >>>
> > >>> 1.
> > >>>
> > >>> I also think that requiring +1 from another committer would slow down
> > and put even more strain on the current reviewing bottleneck that we are
> > having. Even if the change clear and simple, context switch cost is quite
> > high, and that’s just one less PR that the second “cross” committer could
> > have reviewed somewhere else in that time. Besides, current setup that we
> > have (with no cross +1 from another committer required) works quite well
> > and I do not feel that’s causing troubles. On the other hand reviewing
> > bottleneck is.
> > >>>
> > >>> 2.
> > >>>
> > >>>> I think a committer should know when to ask another committer for
> > feedback or not.
> > >>> I’m missing this stated somewhere clearly. If we are stating that a
> > single committers +1 is good enough for code review, with 0 hours delay
> (de
> > facto the current state), we should also write down that this is subject
> to
> > the best judgement of the committer to respect the components expertise
> and
> > ongoing development plans (also the de facto current state).
> > >>>
> > >>> 3.
> > >>>
> > >>> Minimum length of 3 days for FLIP I think currently might be
> > problematic/too quick and can lead to problems if respected to the
> letter.
> > Again I think it depends highly on whether the committers with highest
> > expertise in the affected components managed to respond or not.
> > >>>
> > >>> Piotrek
> > >>>
> > >>>> On 12 Jul 2019, at 09:42, Chesnay Schepler <[hidden email]>
> > wrote:
> > >>>>
> > >>>> I'm wondering whether we shouldn't first write down Bylaws that
> > reflect the current state, and then have separate discussions for
> > individual amendments. My gut feeling is that this discussion will
> quickly
> > become a chaotic mess with plenty points being discussed at once.
> > >>>>
> > >>>> On 11/07/2019 20:03, Bowen Li wrote:
> > >>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket Qin <[hidden email]>
> > wrote:
> > >>>>>
> > >>>>>> Thanks everyone for all the comments and feedback. Please see the
> > replies
> > >>>>>> below:
> > >>>>>>
> > >>>>>> --------------------------------
> > >>>>>> Re: Konstantin
> > >>>>>>
> > >>>>>>> * 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.
> > >>>>>> Good point. Just added the entry.
> > >>>>>>
> > >>>>>> -------------------------------
> > >>>>>> Re: Konstantin
> > >>>>>>
> > >>>>>>> * 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.
> > >>>>>> & Re: Till
> > >>>>>>
> > >>>>>>> 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.
> > >>>>>> I am with Robert and Aljoscha on this.
> > >>>>>>
> > >>>>>> I completely understand the concern here. TBH, in Kafka
> occasionally
> > >>>>>> trivial patches from committers are still merged without following
> > the
> > >>>>>> cross-review requirement, but it is rare. That said, I still think
> > an
> > >>>>>> additional committer's review makes sense due to the following
> > reasons:
> > >>>>>> 1. The bottom line here is that we need to make sure every patch
> is
> > >>>>>> reviewed with a high quality. This is a little difficult to
> > guarantee if
> > >>>>>> the review comes from a contributor for many reasons. In some
> > cases, a
> > >>>>>> contributor may not have enough knowledge about the project to
> make
> > a good
> > >>>>>> judgement. Also sometimes the contributors are more eagerly to
> get a
> > >>>>>> particular issue fixed, so they are willing to lower the review
> bar.
> > >>>>>> 2. One byproduct of such cross review among committers, which I
> > personally
> > >>>>>> feel useful, is that it helps gradually form consistent design
> > principles
> > >>>>>> and code style. This is because the committers will know how the
> > other
> > >>>>>> committers are writing code and learn from each other. So they
> tend
> > to
> > >>>>>> reach some tacit understanding on how things should be done in
> > general.
> > >>>>>>
> > >>>>>> Another way to think about this is to consider the following two
> > scenarios:
> > >>>>>> 1. Reviewing a committer's patch takes a lot of iterations. Then
> > the patch
> > >>>>>> needs to be reviewed even if it takes time because there are
> things
> > >>>>>> actually needs to be clarified / changed.
> > >>>>>> 2. Reviewing a committer's patch is very smooth and quick, so the
> > patch is
> > >>>>>> merged soon. Then reviewing such a patch does not take much time.
> > >>>>>>
> > >>>>>> Letting another committer review the patch from a committer falls
> > either in
> > >>>>>> case 1 or case 2. The best option here is to review the patch
> > because
> > >>>>>> If it is case 1, the patch actually needs to be reviewed.
> > >>>>>> If it is case 2, the review should not take much time anyways.
> > >>>>>>
> > >>>>>> In the contrast, we will risk encounter case 1 if we skip the
> > cross-review.
> > >>>>>>
> > >>>>>> ------------------------
> > >>>>>> Re: Robert
> > >>>>>>
> > >>>>>> I replied to your comments in the wiki and made the following
> > modifications
> > >>>>>> to resolve some of your comments:
> > >>>>>> 1. Added a release manager role section.
> > >>>>>> 2. changed the name of "lazy consensus" to "consensus" to align
> with
> > >>>>>> general definition of Apache glossary and other projects.
> > >>>>>> 3. review board  -> pull request
> > >>>>>>
> > >>>>>> -------------------------
> > >>>>>> Re: Chesnay
> > >>>>>>
> > >>>>>> The emeritus stuff seems like unnecessary noise.
> > >>>>>> As Till mentioned, this is to make sure 2/3 majority is still
> > feasible in
> > >>>>>> practice.
> > >>>>>>
> > >>>>>> 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.
> > >>>>>> That is a good suggestion. I am not familiar enough with the
> > current Flink
> > >>>>>> convention. Will you help on this? I saw you commented on some
> part
> > in the
> > >>>>>> wiki. Are those complete?
> > >>>>>>
> > >>>>>> --------------------------
> > >>>>>> Re: Aljoscha
> > >>>>>>
> > >>>>>> 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.
> > >>>>>> Ha, you got me on this. The first version of the draft was almost
> > identical
> > >>>>>> to Kafka. But Robert has already caught a few inconsistent places.
> > So it
> > >>>>>> might still worth going through it to make sure we truly agree on
> > them.
> > >>>>>> Otherwise we may end up modifying them shortly after adoption.
> > >>>>>>
> > >>>>>>
> > >>>>>> Thanks again folks, for all the valuable feedback. These are great
> > >>>>>> discussion.
> > >>>>>>
> > >>>>>> Jiangjie (Becket) Qin
> > >>>>>>
> > >>>>>> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha Krettek <
> > [hidden email]>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> Big +1
> > >>>>>>>
> > >>>>>>> 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.
> > >>>>>>>
> > >>>>>>> Aljoscha
> > >>>>>>>
> > >>>>>>>> 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
> > >>>>>>>>>>>
> > >>>>>>>>>>> [phone]
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> 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
> > >>>>>>>>>>>
> >
> >
>

[Becket Qin]

Hi Jincheng,

Thanks for the comments. I replied on the wiki page. Just a brief summary,
the current bylaws do require some of the FLIPs to get PMC approval if
their impact is big enough. But it leaves majority of the technical
decisions to the committers who are supposed to be responsible for making
such decisions.

Re: Robert,

I agree we can simply remove the requirement of +1 from a non-author
committer and revisit it in a bit. After all, it does not make sense to
have a bylaw that we cannot afford. I have just updated the bylaws wiki.

Thanks,

Jiangjie (Becket) Qin

On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <[hidden email]> wrote:

> Hi all,
> I agree with Aljoscha that trying to reflect the current status in the
> bylaws, and then implementing changes one by one is a very involved task.
> Unless there's somebody who's really eager to drive this, I would stick to
> Becket's initiative to come up with Bylaws for Flink, even if this means
> some changes.
>
> The cross-review requirement is the last big open point in this discussion.
> It seems that a there is a slight tendency in the discussion that this is
> not feasible given the current pull request review situation.
> For the sake of bringing this discussion to a conclusion, I'm fine with
> leaving this requirement out. As we are currently adding more committers to
> the project, we might be able to revisit this discussion in 3 - 6 months.
>
>
> On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <[hidden email]>
> wrote:
>
> > Hi Becket,
> >
> > Thanks for the proposal.
> >
> > Regarding the vote of FLIP, preferably at least includes a PMC vote.
> > Because FLIP is usually a big change or affects the user's interface
> > changes. What do you think? (I leave the comment in the wiki.)
> >
> > Best,
> > Jincheng
> >
> > Dawid Wysakowicz <[hidden email]> 于2019年7月17日周三 下午9:12写道：
> >
> > > Hi all,
> > >
> > > Sorry for joining late. I just wanted to say that I really like the
> > > proposed bylaws!
> > >
> > > One comment, I also have the same concerns as expressed by few people
> > > before that the "committer +1" on code change might be hard to achieve
> > > currently. On the other hand I would say this would be beneficial for
> > > the quality/uniformity of our codebase and knowledge sharing.
> > >
> > > I was just wondering what should be the next step for this? I think it
> > > would make sense to already use those bylaws and put them to PMC vote.
> > >
> > > Best,
> > >
> > > Dawid
> > >
> > > On 12/07/2019 13:35, Piotr Nowojski wrote:
> > > > Hi Aljoscha and Becket
> > > >
> > > > Right, 3 days for FLIP voting is fine I think.
> > > >
> > > >>> I’m missing this stated somewhere clearly. If we are stating that a
> > > single
> > > >>> committers +1 is good enough for code review, with 0 hours delay
> (de
> > > facto
> > > >>> the current state), we should also write down that this is subject
> to
> > > the
> > > >>> best judgement of the committer to respect the components expertise
> > and
> > > >>> ongoing development plans (also the de facto current state).
> > > >> Adding the statement would help clarify the intention, but it may
> be a
> > > >> little difficult to enforce and follow..
> > > > I would be fine with that, it’s a soft/vague rule anyway, intended to
> > be
> > > used with your “best judgemenet". I would like to just avoid a
> situation
> > > when someone violates current uncodified state and refers to the bylaws
> > > which are saying merging with any committer +1 is always fine (like
> mine
> > +1
> > > for flink-python or flink-ml).
> > > >
> > > > Piotrek
> > > >
> > > >> On 12 Jul 2019, at 11:29, Aljoscha Krettek <[hidden email]>
> > wrote:
> > > >>
> > > >> @Piotr regarding the 3 days voting on the FLIP. This is just about
> the
> > > voting, before that there needs to be the discussion thread. If three
> > days
> > > have passed on a vote and there is consensus (i.e. 3 committers/PMCs
> have
> > > voted +1) that seems a high enough bar for me. So far, we have rarely
> see
> > > any FLIPs pass that formal bar.
> > > >>
> > > >> According to the recent META-FLIP thread, we want to use "lazy
> > > majority" for the FLIP voting process. I think that should be changed
> > from
> > > “consensus” in the proposed bylaws.
> > > >>
> > > >> Regarding the current state: do we have a current state that we all
> > > agree on? I have the feeling that if we try to come up with something
> > that
> > > reflects the common state, according to PMCs/commiters, that might
> take a
> > > very long time. In that case I think it’s better to adopt something
> that
> > we
> > > all like, rather than trying to capture how we do it now.
> > > >>
> > > >> Aljoscha
> > > >>
> > > >>> On 12. Jul 2019, at 11:07, Piotr Nowojski <[hidden email]>
> > wrote:
> > > >>>
> > > >>> Hi,
> > > >>>
> > > >>> Thanks for the proposal. Generally speaking +1 from my side to the
> > > general idea and most of the content. I also see merit to the Chesney's
> > > proposal to start from the current state. I think either would be fine
> > for
> > > me.
> > > >>>
> > > >>> Couple of comments:
> > > >>>
> > > >>> 1.
> > > >>>
> > > >>> I also think that requiring +1 from another committer would slow
> down
> > > and put even more strain on the current reviewing bottleneck that we
> are
> > > having. Even if the change clear and simple, context switch cost is
> quite
> > > high, and that’s just one less PR that the second “cross” committer
> could
> > > have reviewed somewhere else in that time. Besides, current setup that
> we
> > > have (with no cross +1 from another committer required) works quite
> well
> > > and I do not feel that’s causing troubles. On the other hand reviewing
> > > bottleneck is.
> > > >>>
> > > >>> 2.
> > > >>>
> > > >>>> I think a committer should know when to ask another committer for
> > > feedback or not.
> > > >>> I’m missing this stated somewhere clearly. If we are stating that a
> > > single committers +1 is good enough for code review, with 0 hours delay
> > (de
> > > facto the current state), we should also write down that this is
> subject
> > to
> > > the best judgement of the committer to respect the components expertise
> > and
> > > ongoing development plans (also the de facto current state).
> > > >>>
> > > >>> 3.
> > > >>>
> > > >>> Minimum length of 3 days for FLIP I think currently might be
> > > problematic/too quick and can lead to problems if respected to the
> > letter.
> > > Again I think it depends highly on whether the committers with highest
> > > expertise in the affected components managed to respond or not.
> > > >>>
> > > >>> Piotrek
> > > >>>
> > > >>>> On 12 Jul 2019, at 09:42, Chesnay Schepler <[hidden email]>
> > > wrote:
> > > >>>>
> > > >>>> I'm wondering whether we shouldn't first write down Bylaws that
> > > reflect the current state, and then have separate discussions for
> > > individual amendments. My gut feeling is that this discussion will
> > quickly
> > > become a chaotic mess with plenty points being discussed at once.
> > > >>>>
> > > >>>> On 11/07/2019 20:03, Bowen Li wrote:
> > > >>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket Qin <
> [hidden email]>
> > > wrote:
> > > >>>>>
> > > >>>>>> Thanks everyone for all the comments and feedback. Please see
> the
> > > replies
> > > >>>>>> below:
> > > >>>>>>
> > > >>>>>> --------------------------------
> > > >>>>>> Re: Konstantin
> > > >>>>>>
> > > >>>>>>> * 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.
> > > >>>>>> Good point. Just added the entry.
> > > >>>>>>
> > > >>>>>> -------------------------------
> > > >>>>>> Re: Konstantin
> > > >>>>>>
> > > >>>>>>> * 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.
> > > >>>>>> & Re: Till
> > > >>>>>>
> > > >>>>>>> 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.
> > > >>>>>> I am with Robert and Aljoscha on this.
> > > >>>>>>
> > > >>>>>> I completely understand the concern here. TBH, in Kafka
> > occasionally
> > > >>>>>> trivial patches from committers are still merged without
> following
> > > the
> > > >>>>>> cross-review requirement, but it is rare. That said, I still
> think
> > > an
> > > >>>>>> additional committer's review makes sense due to the following
> > > reasons:
> > > >>>>>> 1. The bottom line here is that we need to make sure every patch
> > is
> > > >>>>>> reviewed with a high quality. This is a little difficult to
> > > guarantee if
> > > >>>>>> the review comes from a contributor for many reasons. In some
> > > cases, a
> > > >>>>>> contributor may not have enough knowledge about the project to
> > make
> > > a good
> > > >>>>>> judgement. Also sometimes the contributors are more eagerly to
> > get a
> > > >>>>>> particular issue fixed, so they are willing to lower the review
> > bar.
> > > >>>>>> 2. One byproduct of such cross review among committers, which I
> > > personally
> > > >>>>>> feel useful, is that it helps gradually form consistent design
> > > principles
> > > >>>>>> and code style. This is because the committers will know how the
> > > other
> > > >>>>>> committers are writing code and learn from each other. So they
> > tend
> > > to
> > > >>>>>> reach some tacit understanding on how things should be done in
> > > general.
> > > >>>>>>
> > > >>>>>> Another way to think about this is to consider the following two
> > > scenarios:
> > > >>>>>> 1. Reviewing a committer's patch takes a lot of iterations. Then
> > > the patch
> > > >>>>>> needs to be reviewed even if it takes time because there are
> > things
> > > >>>>>> actually needs to be clarified / changed.
> > > >>>>>> 2. Reviewing a committer's patch is very smooth and quick, so
> the
> > > patch is
> > > >>>>>> merged soon. Then reviewing such a patch does not take much
> time.
> > > >>>>>>
> > > >>>>>> Letting another committer review the patch from a committer
> falls
> > > either in
> > > >>>>>> case 1 or case 2. The best option here is to review the patch
> > > because
> > > >>>>>> If it is case 1, the patch actually needs to be reviewed.
> > > >>>>>> If it is case 2, the review should not take much time anyways.
> > > >>>>>>
> > > >>>>>> In the contrast, we will risk encounter case 1 if we skip the
> > > cross-review.
> > > >>>>>>
> > > >>>>>> ------------------------
> > > >>>>>> Re: Robert
> > > >>>>>>
> > > >>>>>> I replied to your comments in the wiki and made the following
> > > modifications
> > > >>>>>> to resolve some of your comments:
> > > >>>>>> 1. Added a release manager role section.
> > > >>>>>> 2. changed the name of "lazy consensus" to "consensus" to align
> > with
> > > >>>>>> general definition of Apache glossary and other projects.
> > > >>>>>> 3. review board  -> pull request
> > > >>>>>>
> > > >>>>>> -------------------------
> > > >>>>>> Re: Chesnay
> > > >>>>>>
> > > >>>>>> The emeritus stuff seems like unnecessary noise.
> > > >>>>>> As Till mentioned, this is to make sure 2/3 majority is still
> > > feasible in
> > > >>>>>> practice.
> > > >>>>>>
> > > >>>>>> 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.
> > > >>>>>> That is a good suggestion. I am not familiar enough with the
> > > current Flink
> > > >>>>>> convention. Will you help on this? I saw you commented on some
> > part
> > > in the
> > > >>>>>> wiki. Are those complete?
> > > >>>>>>
> > > >>>>>> --------------------------
> > > >>>>>> Re: Aljoscha
> > > >>>>>>
> > > >>>>>> 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.
> > > >>>>>> Ha, you got me on this. The first version of the draft was
> almost
> > > identical
> > > >>>>>> to Kafka. But Robert has already caught a few inconsistent
> places.
> > > So it
> > > >>>>>> might still worth going through it to make sure we truly agree
> on
> > > them.
> > > >>>>>> Otherwise we may end up modifying them shortly after adoption.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> Thanks again folks, for all the valuable feedback. These are
> great
> > > >>>>>> discussion.
> > > >>>>>>
> > > >>>>>> Jiangjie (Becket) Qin
> > > >>>>>>
> > > >>>>>> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha Krettek <
> > > [hidden email]>
> > > >>>>>> wrote:
> > > >>>>>>
> > > >>>>>>> Big +1
> > > >>>>>>>
> > > >>>>>>> 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.
> > > >>>>>>>
> > > >>>>>>> Aljoscha
> > > >>>>>>>
> > > >>>>>>>> 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
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> [phone]
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 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
> > > >>>>>>>>>>>
> > >
> > >
> >
>

[Hequn Cheng]

Hi Becket,

Big +1 on this.

> Regarding the vote of FLIP, preferably at least includes a PMC vote.
Perhaps what Jincheng means is to hold at least one PMC in the 3 binding
votes? i.e, the vote could have 2 binding committers and 1 PMC.
I think this makes sense considering a FLIP could somehow be a big feature
which may impacts Flink a lot. Meanwhile, there is no loss of flexibility
as committers also have a chance to vote and participate in it.

========Seperator========

For the nice bylaws, I agree with the general idea and most of the content.
Only share some thoughts about the "2/3 Majority". The main concern is I am
not sure if it is doable in practice. The reasons are:

1. If we follow the bylaws strictly, it means a committer or a PMC member
is active if he or she sends one email to the mailing list every 6 months.
While the minimum length of the vote is only 6 days. There are chances that
during the vote, some of the active members are still offline of the
community.
2. The code of Flink is changing fast and not everyone fully understands
every part. We don't need to force people to vote if they are not sure
about it. It may also make the final result less credible.

Given the above reasons, perhaps we can change the 2/3 Majority to lazy 2/3
Majority, just as the Hadoop bylaws[1]. It makes a higher threshold,
however, more practical.

What do you think?

[1] https://hadoop.apache.org/bylaws.html

On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <[hidden email]> wrote:

> Hi Jincheng,
>
> Thanks for the comments. I replied on the wiki page. Just a brief summary,
> the current bylaws do require some of the FLIPs to get PMC approval if
> their impact is big enough. But it leaves majority of the technical
> decisions to the committers who are supposed to be responsible for making
> such decisions.
>
> Re: Robert,
>
> I agree we can simply remove the requirement of +1 from a non-author
> committer and revisit it in a bit. After all, it does not make sense to
> have a bylaw that we cannot afford. I have just updated the bylaws wiki.
>
> Thanks,
>
> Jiangjie (Becket) Qin
>
> On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <[hidden email]>
> wrote:
>
> > Hi all,
> > I agree with Aljoscha that trying to reflect the current status in the
> > bylaws, and then implementing changes one by one is a very involved task.
> > Unless there's somebody who's really eager to drive this, I would stick
> to
> > Becket's initiative to come up with Bylaws for Flink, even if this means
> > some changes.
> >
> > The cross-review requirement is the last big open point in this
> discussion.
> > It seems that a there is a slight tendency in the discussion that this is
> > not feasible given the current pull request review situation.
> > For the sake of bringing this discussion to a conclusion, I'm fine with
> > leaving this requirement out. As we are currently adding more committers
> to
> > the project, we might be able to revisit this discussion in 3 - 6 months.
> >
> >
> > On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <[hidden email]>
> > wrote:
> >
> > > Hi Becket,
> > >
> > > Thanks for the proposal.
> > >
> > > Regarding the vote of FLIP, preferably at least includes a PMC vote.
> > > Because FLIP is usually a big change or affects the user's interface
> > > changes. What do you think? (I leave the comment in the wiki.)
> > >
> > > Best,
> > > Jincheng
> > >
> > > Dawid Wysakowicz <[hidden email]> 于2019年7月17日周三 下午9:12写道：
> > >
> > > > Hi all,
> > > >
> > > > Sorry for joining late. I just wanted to say that I really like the
> > > > proposed bylaws!
> > > >
> > > > One comment, I also have the same concerns as expressed by few people
> > > > before that the "committer +1" on code change might be hard to
> achieve
> > > > currently. On the other hand I would say this would be beneficial for
> > > > the quality/uniformity of our codebase and knowledge sharing.
> > > >
> > > > I was just wondering what should be the next step for this? I think
> it
> > > > would make sense to already use those bylaws and put them to PMC
> vote.
> > > >
> > > > Best,
> > > >
> > > > Dawid
> > > >
> > > > On 12/07/2019 13:35, Piotr Nowojski wrote:
> > > > > Hi Aljoscha and Becket
> > > > >
> > > > > Right, 3 days for FLIP voting is fine I think.
> > > > >
> > > > >>> I’m missing this stated somewhere clearly. If we are stating
> that a
> > > > single
> > > > >>> committers +1 is good enough for code review, with 0 hours delay
> > (de
> > > > facto
> > > > >>> the current state), we should also write down that this is
> subject
> > to
> > > > the
> > > > >>> best judgement of the committer to respect the components
> expertise
> > > and
> > > > >>> ongoing development plans (also the de facto current state).
> > > > >> Adding the statement would help clarify the intention, but it may
> > be a
> > > > >> little difficult to enforce and follow..
> > > > > I would be fine with that, it’s a soft/vague rule anyway, intended
> to
> > > be
> > > > used with your “best judgemenet". I would like to just avoid a
> > situation
> > > > when someone violates current uncodified state and refers to the
> bylaws
> > > > which are saying merging with any committer +1 is always fine (like
> > mine
> > > +1
> > > > for flink-python or flink-ml).
> > > > >
> > > > > Piotrek
> > > > >
> > > > >> On 12 Jul 2019, at 11:29, Aljoscha Krettek <[hidden email]>
> > > wrote:
> > > > >>
> > > > >> @Piotr regarding the 3 days voting on the FLIP. This is just about
> > the
> > > > voting, before that there needs to be the discussion thread. If three
> > > days
> > > > have passed on a vote and there is consensus (i.e. 3 committers/PMCs
> > have
> > > > voted +1) that seems a high enough bar for me. So far, we have rarely
> > see
> > > > any FLIPs pass that formal bar.
> > > > >>
> > > > >> According to the recent META-FLIP thread, we want to use "lazy
> > > > majority" for the FLIP voting process. I think that should be changed
> > > from
> > > > “consensus” in the proposed bylaws.
> > > > >>
> > > > >> Regarding the current state: do we have a current state that we
> all
> > > > agree on? I have the feeling that if we try to come up with something
> > > that
> > > > reflects the common state, according to PMCs/commiters, that might
> > take a
> > > > very long time. In that case I think it’s better to adopt something
> > that
> > > we
> > > > all like, rather than trying to capture how we do it now.
> > > > >>
> > > > >> Aljoscha
> > > > >>
> > > > >>> On 12. Jul 2019, at 11:07, Piotr Nowojski <[hidden email]>
> > > wrote:
> > > > >>>
> > > > >>> Hi,
> > > > >>>
> > > > >>> Thanks for the proposal. Generally speaking +1 from my side to
> the
> > > > general idea and most of the content. I also see merit to the
> Chesney's
> > > > proposal to start from the current state. I think either would be
> fine
> > > for
> > > > me.
> > > > >>>
> > > > >>> Couple of comments:
> > > > >>>
> > > > >>> 1.
> > > > >>>
> > > > >>> I also think that requiring +1 from another committer would slow
> > down
> > > > and put even more strain on the current reviewing bottleneck that we
> > are
> > > > having. Even if the change clear and simple, context switch cost is
> > quite
> > > > high, and that’s just one less PR that the second “cross” committer
> > could
> > > > have reviewed somewhere else in that time. Besides, current setup
> that
> > we
> > > > have (with no cross +1 from another committer required) works quite
> > well
> > > > and I do not feel that’s causing troubles. On the other hand
> reviewing
> > > > bottleneck is.
> > > > >>>
> > > > >>> 2.
> > > > >>>
> > > > >>>> I think a committer should know when to ask another committer
> for
> > > > feedback or not.
> > > > >>> I’m missing this stated somewhere clearly. If we are stating
> that a
> > > > single committers +1 is good enough for code review, with 0 hours
> delay
> > > (de
> > > > facto the current state), we should also write down that this is
> > subject
> > > to
> > > > the best judgement of the committer to respect the components
> expertise
> > > and
> > > > ongoing development plans (also the de facto current state).
> > > > >>>
> > > > >>> 3.
> > > > >>>
> > > > >>> Minimum length of 3 days for FLIP I think currently might be
> > > > problematic/too quick and can lead to problems if respected to the
> > > letter.
> > > > Again I think it depends highly on whether the committers with
> highest
> > > > expertise in the affected components managed to respond or not.
> > > > >>>
> > > > >>> Piotrek
> > > > >>>
> > > > >>>> On 12 Jul 2019, at 09:42, Chesnay Schepler <[hidden email]>
> > > > wrote:
> > > > >>>>
> > > > >>>> I'm wondering whether we shouldn't first write down Bylaws that
> > > > reflect the current state, and then have separate discussions for
> > > > individual amendments. My gut feeling is that this discussion will
> > > quickly
> > > > become a chaotic mess with plenty points being discussed at once.
> > > > >>>>
> > > > >>>> On 11/07/2019 20:03, Bowen Li wrote:
> > > > >>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket Qin <
> > [hidden email]>
> > > > wrote:
> > > > >>>>>
> > > > >>>>>> Thanks everyone for all the comments and feedback. Please see
> > the
> > > > replies
> > > > >>>>>> below:
> > > > >>>>>>
> > > > >>>>>> --------------------------------
> > > > >>>>>> Re: Konstantin
> > > > >>>>>>
> > > > >>>>>>> * 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.
> > > > >>>>>> Good point. Just added the entry.
> > > > >>>>>>
> > > > >>>>>> -------------------------------
> > > > >>>>>> Re: Konstantin
> > > > >>>>>>
> > > > >>>>>>> * 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.
> > > > >>>>>> & Re: Till
> > > > >>>>>>
> > > > >>>>>>> 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.
> > > > >>>>>> I am with Robert and Aljoscha on this.
> > > > >>>>>>
> > > > >>>>>> I completely understand the concern here. TBH, in Kafka
> > > occasionally
> > > > >>>>>> trivial patches from committers are still merged without
> > following
> > > > the
> > > > >>>>>> cross-review requirement, but it is rare. That said, I still
> > think
> > > > an
> > > > >>>>>> additional committer's review makes sense due to the following
> > > > reasons:
> > > > >>>>>> 1. The bottom line here is that we need to make sure every
> patch
> > > is
> > > > >>>>>> reviewed with a high quality. This is a little difficult to
> > > > guarantee if
> > > > >>>>>> the review comes from a contributor for many reasons. In some
> > > > cases, a
> > > > >>>>>> contributor may not have enough knowledge about the project to
> > > make
> > > > a good
> > > > >>>>>> judgement. Also sometimes the contributors are more eagerly to
> > > get a
> > > > >>>>>> particular issue fixed, so they are willing to lower the
> review
> > > bar.
> > > > >>>>>> 2. One byproduct of such cross review among committers, which
> I
> > > > personally
> > > > >>>>>> feel useful, is that it helps gradually form consistent design
> > > > principles
> > > > >>>>>> and code style. This is because the committers will know how
> the
> > > > other
> > > > >>>>>> committers are writing code and learn from each other. So they
> > > tend
> > > > to
> > > > >>>>>> reach some tacit understanding on how things should be done in
> > > > general.
> > > > >>>>>>
> > > > >>>>>> Another way to think about this is to consider the following
> two
> > > > scenarios:
> > > > >>>>>> 1. Reviewing a committer's patch takes a lot of iterations.
> Then
> > > > the patch
> > > > >>>>>> needs to be reviewed even if it takes time because there are
> > > things
> > > > >>>>>> actually needs to be clarified / changed.
> > > > >>>>>> 2. Reviewing a committer's patch is very smooth and quick, so
> > the
> > > > patch is
> > > > >>>>>> merged soon. Then reviewing such a patch does not take much
> > time.
> > > > >>>>>>
> > > > >>>>>> Letting another committer review the patch from a committer
> > falls
> > > > either in
> > > > >>>>>> case 1 or case 2. The best option here is to review the patch
> > > > because
> > > > >>>>>> If it is case 1, the patch actually needs to be reviewed.
> > > > >>>>>> If it is case 2, the review should not take much time anyways.
> > > > >>>>>>
> > > > >>>>>> In the contrast, we will risk encounter case 1 if we skip the
> > > > cross-review.
> > > > >>>>>>
> > > > >>>>>> ------------------------
> > > > >>>>>> Re: Robert
> > > > >>>>>>
> > > > >>>>>> I replied to your comments in the wiki and made the following
> > > > modifications
> > > > >>>>>> to resolve some of your comments:
> > > > >>>>>> 1. Added a release manager role section.
> > > > >>>>>> 2. changed the name of "lazy consensus" to "consensus" to
> align
> > > with
> > > > >>>>>> general definition of Apache glossary and other projects.
> > > > >>>>>> 3. review board  -> pull request
> > > > >>>>>>
> > > > >>>>>> -------------------------
> > > > >>>>>> Re: Chesnay
> > > > >>>>>>
> > > > >>>>>> The emeritus stuff seems like unnecessary noise.
> > > > >>>>>> As Till mentioned, this is to make sure 2/3 majority is still
> > > > feasible in
> > > > >>>>>> practice.
> > > > >>>>>>
> > > > >>>>>> 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.
> > > > >>>>>> That is a good suggestion. I am not familiar enough with the
> > > > current Flink
> > > > >>>>>> convention. Will you help on this? I saw you commented on some
> > > part
> > > > in the
> > > > >>>>>> wiki. Are those complete?
> > > > >>>>>>
> > > > >>>>>> --------------------------
> > > > >>>>>> Re: Aljoscha
> > > > >>>>>>
> > > > >>>>>> 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.
> > > > >>>>>> Ha, you got me on this. The first version of the draft was
> > almost
> > > > identical
> > > > >>>>>> to Kafka. But Robert has already caught a few inconsistent
> > places.
> > > > So it
> > > > >>>>>> might still worth going through it to make sure we truly agree
> > on
> > > > them.
> > > > >>>>>> Otherwise we may end up modifying them shortly after adoption.
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>> Thanks again folks, for all the valuable feedback. These are
> > great
> > > > >>>>>> discussion.
> > > > >>>>>>
> > > > >>>>>> Jiangjie (Becket) Qin
> > > > >>>>>>
> > > > >>>>>> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha Krettek <
> > > > [hidden email]>
> > > > >>>>>> wrote:
> > > > >>>>>>
> > > > >>>>>>> Big +1
> > > > >>>>>>>
> > > > >>>>>>> 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.
> > > > >>>>>>>
> > > > >>>>>>> Aljoscha
> > > > >>>>>>>
> > > > >>>>>>>> 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
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> [phone]
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> 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
> > > > >>>>>>>>>>>
> > > >
> > > >
> > >
> >
>

[Forward Xu]

Big +1 on this.


best

forward

Hequn Cheng <[hidden email]> 于2019年7月21日周日 下午1:30写道：

> Hi Becket,
>
> Big +1 on this.
>
> > Regarding the vote of FLIP, preferably at least includes a PMC vote.
> Perhaps what Jincheng means is to hold at least one PMC in the 3 binding
> votes? i.e, the vote could have 2 binding committers and 1 PMC.
> I think this makes sense considering a FLIP could somehow be a big feature
> which may impacts Flink a lot. Meanwhile, there is no loss of flexibility
> as committers also have a chance to vote and participate in it.
>
> ========Seperator========
>
> For the nice bylaws, I agree with the general idea and most of the content.
> Only share some thoughts about the "2/3 Majority". The main concern is I am
> not sure if it is doable in practice. The reasons are:
>
> 1. If we follow the bylaws strictly, it means a committer or a PMC member
> is active if he or she sends one email to the mailing list every 6 months.
> While the minimum length of the vote is only 6 days. There are chances that
> during the vote, some of the active members are still offline of the
> community.
> 2. The code of Flink is changing fast and not everyone fully understands
> every part. We don't need to force people to vote if they are not sure
> about it. It may also make the final result less credible.
>
> Given the above reasons, perhaps we can change the 2/3 Majority to lazy 2/3
> Majority, just as the Hadoop bylaws[1]. It makes a higher threshold,
> however, more practical.
>
> What do you think?
>
> [1] https://hadoop.apache.org/bylaws.html
>
> On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <[hidden email]> wrote:
>
> > Hi Jincheng,
> >
> > Thanks for the comments. I replied on the wiki page. Just a brief
> summary,
> > the current bylaws do require some of the FLIPs to get PMC approval if
> > their impact is big enough. But it leaves majority of the technical
> > decisions to the committers who are supposed to be responsible for making
> > such decisions.
> >
> > Re: Robert,
> >
> > I agree we can simply remove the requirement of +1 from a non-author
> > committer and revisit it in a bit. After all, it does not make sense to
> > have a bylaw that we cannot afford. I have just updated the bylaws wiki.
> >
> > Thanks,
> >
> > Jiangjie (Becket) Qin
> >
> > On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <[hidden email]>
> > wrote:
> >
> > > Hi all,
> > > I agree with Aljoscha that trying to reflect the current status in the
> > > bylaws, and then implementing changes one by one is a very involved
> task.
> > > Unless there's somebody who's really eager to drive this, I would stick
> > to
> > > Becket's initiative to come up with Bylaws for Flink, even if this
> means
> > > some changes.
> > >
> > > The cross-review requirement is the last big open point in this
> > discussion.
> > > It seems that a there is a slight tendency in the discussion that this
> is
> > > not feasible given the current pull request review situation.
> > > For the sake of bringing this discussion to a conclusion, I'm fine with
> > > leaving this requirement out. As we are currently adding more
> committers
> > to
> > > the project, we might be able to revisit this discussion in 3 - 6
> months.
> > >
> > >
> > > On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <[hidden email]
> >
> > > wrote:
> > >
> > > > Hi Becket,
> > > >
> > > > Thanks for the proposal.
> > > >
> > > > Regarding the vote of FLIP, preferably at least includes a PMC vote.
> > > > Because FLIP is usually a big change or affects the user's interface
> > > > changes. What do you think? (I leave the comment in the wiki.)
> > > >
> > > > Best,
> > > > Jincheng
> > > >
> > > > Dawid Wysakowicz <[hidden email]> 于2019年7月17日周三 下午9:12写道：
> > > >
> > > > > Hi all,
> > > > >
> > > > > Sorry for joining late. I just wanted to say that I really like the
> > > > > proposed bylaws!
> > > > >
> > > > > One comment, I also have the same concerns as expressed by few
> people
> > > > > before that the "committer +1" on code change might be hard to
> > achieve
> > > > > currently. On the other hand I would say this would be beneficial
> for
> > > > > the quality/uniformity of our codebase and knowledge sharing.
> > > > >
> > > > > I was just wondering what should be the next step for this? I think
> > it
> > > > > would make sense to already use those bylaws and put them to PMC
> > vote.
> > > > >
> > > > > Best,
> > > > >
> > > > > Dawid
> > > > >
> > > > > On 12/07/2019 13:35, Piotr Nowojski wrote:
> > > > > > Hi Aljoscha and Becket
> > > > > >
> > > > > > Right, 3 days for FLIP voting is fine I think.
> > > > > >
> > > > > >>> I’m missing this stated somewhere clearly. If we are stating
> > that a
> > > > > single
> > > > > >>> committers +1 is good enough for code review, with 0 hours
> delay
> > > (de
> > > > > facto
> > > > > >>> the current state), we should also write down that this is
> > subject
> > > to
> > > > > the
> > > > > >>> best judgement of the committer to respect the components
> > expertise
> > > > and
> > > > > >>> ongoing development plans (also the de facto current state).
> > > > > >> Adding the statement would help clarify the intention, but it
> may
> > > be a
> > > > > >> little difficult to enforce and follow..
> > > > > > I would be fine with that, it’s a soft/vague rule anyway,
> intended
> > to
> > > > be
> > > > > used with your “best judgemenet". I would like to just avoid a
> > > situation
> > > > > when someone violates current uncodified state and refers to the
> > bylaws
> > > > > which are saying merging with any committer +1 is always fine (like
> > > mine
> > > > +1
> > > > > for flink-python or flink-ml).
> > > > > >
> > > > > > Piotrek
> > > > > >
> > > > > >> On 12 Jul 2019, at 11:29, Aljoscha Krettek <[hidden email]
> >
> > > > wrote:
> > > > > >>
> > > > > >> @Piotr regarding the 3 days voting on the FLIP. This is just
> about
> > > the
> > > > > voting, before that there needs to be the discussion thread. If
> three
> > > > days
> > > > > have passed on a vote and there is consensus (i.e. 3
> committers/PMCs
> > > have
> > > > > voted +1) that seems a high enough bar for me. So far, we have
> rarely
> > > see
> > > > > any FLIPs pass that formal bar.
> > > > > >>
> > > > > >> According to the recent META-FLIP thread, we want to use "lazy
> > > > > majority" for the FLIP voting process. I think that should be
> changed
> > > > from
> > > > > “consensus” in the proposed bylaws.
> > > > > >>
> > > > > >> Regarding the current state: do we have a current state that we
> > all
> > > > > agree on? I have the feeling that if we try to come up with
> something
> > > > that
> > > > > reflects the common state, according to PMCs/commiters, that might
> > > take a
> > > > > very long time. In that case I think it’s better to adopt something
> > > that
> > > > we
> > > > > all like, rather than trying to capture how we do it now.
> > > > > >>
> > > > > >> Aljoscha
> > > > > >>
> > > > > >>> On 12. Jul 2019, at 11:07, Piotr Nowojski <[hidden email]
> >
> > > > wrote:
> > > > > >>>
> > > > > >>> Hi,
> > > > > >>>
> > > > > >>> Thanks for the proposal. Generally speaking +1 from my side to
> > the
> > > > > general idea and most of the content. I also see merit to the
> > Chesney's
> > > > > proposal to start from the current state. I think either would be
> > fine
> > > > for
> > > > > me.
> > > > > >>>
> > > > > >>> Couple of comments:
> > > > > >>>
> > > > > >>> 1.
> > > > > >>>
> > > > > >>> I also think that requiring +1 from another committer would
> slow
> > > down
> > > > > and put even more strain on the current reviewing bottleneck that
> we
> > > are
> > > > > having. Even if the change clear and simple, context switch cost is
> > > quite
> > > > > high, and that’s just one less PR that the second “cross” committer
> > > could
> > > > > have reviewed somewhere else in that time. Besides, current setup
> > that
> > > we
> > > > > have (with no cross +1 from another committer required) works quite
> > > well
> > > > > and I do not feel that’s causing troubles. On the other hand
> > reviewing
> > > > > bottleneck is.
> > > > > >>>
> > > > > >>> 2.
> > > > > >>>
> > > > > >>>> I think a committer should know when to ask another committer
> > for
> > > > > feedback or not.
> > > > > >>> I’m missing this stated somewhere clearly. If we are stating
> > that a
> > > > > single committers +1 is good enough for code review, with 0 hours
> > delay
> > > > (de
> > > > > facto the current state), we should also write down that this is
> > > subject
> > > > to
> > > > > the best judgement of the committer to respect the components
> > expertise
> > > > and
> > > > > ongoing development plans (also the de facto current state).
> > > > > >>>
> > > > > >>> 3.
> > > > > >>>
> > > > > >>> Minimum length of 3 days for FLIP I think currently might be
> > > > > problematic/too quick and can lead to problems if respected to the
> > > > letter.
> > > > > Again I think it depends highly on whether the committers with
> > highest
> > > > > expertise in the affected components managed to respond or not.
> > > > > >>>
> > > > > >>> Piotrek
> > > > > >>>
> > > > > >>>> On 12 Jul 2019, at 09:42, Chesnay Schepler <
> [hidden email]>
> > > > > wrote:
> > > > > >>>>
> > > > > >>>> I'm wondering whether we shouldn't first write down Bylaws
> that
> > > > > reflect the current state, and then have separate discussions for
> > > > > individual amendments. My gut feeling is that this discussion will
> > > > quickly
> > > > > become a chaotic mess with plenty points being discussed at once.
> > > > > >>>>
> > > > > >>>> On 11/07/2019 20:03, Bowen Li wrote:
> > > > > >>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket Qin <
> > > [hidden email]>
> > > > > wrote:
> > > > > >>>>>
> > > > > >>>>>> Thanks everyone for all the comments and feedback. Please
> see
> > > the
> > > > > replies
> > > > > >>>>>> below:
> > > > > >>>>>>
> > > > > >>>>>> --------------------------------
> > > > > >>>>>> Re: Konstantin
> > > > > >>>>>>
> > > > > >>>>>>> * 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.
> > > > > >>>>>> Good point. Just added the entry.
> > > > > >>>>>>
> > > > > >>>>>> -------------------------------
> > > > > >>>>>> Re: Konstantin
> > > > > >>>>>>
> > > > > >>>>>>> * 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.
> > > > > >>>>>> & Re: Till
> > > > > >>>>>>
> > > > > >>>>>>> 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.
> > > > > >>>>>> I am with Robert and Aljoscha on this.
> > > > > >>>>>>
> > > > > >>>>>> I completely understand the concern here. TBH, in Kafka
> > > > occasionally
> > > > > >>>>>> trivial patches from committers are still merged without
> > > following
> > > > > the
> > > > > >>>>>> cross-review requirement, but it is rare. That said, I still
> > > think
> > > > > an
> > > > > >>>>>> additional committer's review makes sense due to the
> following
> > > > > reasons:
> > > > > >>>>>> 1. The bottom line here is that we need to make sure every
> > patch
> > > > is
> > > > > >>>>>> reviewed with a high quality. This is a little difficult to
> > > > > guarantee if
> > > > > >>>>>> the review comes from a contributor for many reasons. In
> some
> > > > > cases, a
> > > > > >>>>>> contributor may not have enough knowledge about the project
> to
> > > > make
> > > > > a good
> > > > > >>>>>> judgement. Also sometimes the contributors are more eagerly
> to
> > > > get a
> > > > > >>>>>> particular issue fixed, so they are willing to lower the
> > review
> > > > bar.
> > > > > >>>>>> 2. One byproduct of such cross review among committers,
> which
> > I
> > > > > personally
> > > > > >>>>>> feel useful, is that it helps gradually form consistent
> design
> > > > > principles
> > > > > >>>>>> and code style. This is because the committers will know how
> > the
> > > > > other
> > > > > >>>>>> committers are writing code and learn from each other. So
> they
> > > > tend
> > > > > to
> > > > > >>>>>> reach some tacit understanding on how things should be done
> in
> > > > > general.
> > > > > >>>>>>
> > > > > >>>>>> Another way to think about this is to consider the following
> > two
> > > > > scenarios:
> > > > > >>>>>> 1. Reviewing a committer's patch takes a lot of iterations.
> > Then
> > > > > the patch
> > > > > >>>>>> needs to be reviewed even if it takes time because there are
> > > > things
> > > > > >>>>>> actually needs to be clarified / changed.
> > > > > >>>>>> 2. Reviewing a committer's patch is very smooth and quick,
> so
> > > the
> > > > > patch is
> > > > > >>>>>> merged soon. Then reviewing such a patch does not take much
> > > time.
> > > > > >>>>>>
> > > > > >>>>>> Letting another committer review the patch from a committer
> > > falls
> > > > > either in
> > > > > >>>>>> case 1 or case 2. The best option here is to review the
> patch
> > > > > because
> > > > > >>>>>> If it is case 1, the patch actually needs to be reviewed.
> > > > > >>>>>> If it is case 2, the review should not take much time
> anyways.
> > > > > >>>>>>
> > > > > >>>>>> In the contrast, we will risk encounter case 1 if we skip
> the
> > > > > cross-review.
> > > > > >>>>>>
> > > > > >>>>>> ------------------------
> > > > > >>>>>> Re: Robert
> > > > > >>>>>>
> > > > > >>>>>> I replied to your comments in the wiki and made the
> following
> > > > > modifications
> > > > > >>>>>> to resolve some of your comments:
> > > > > >>>>>> 1. Added a release manager role section.
> > > > > >>>>>> 2. changed the name of "lazy consensus" to "consensus" to
> > align
> > > > with
> > > > > >>>>>> general definition of Apache glossary and other projects.
> > > > > >>>>>> 3. review board  -> pull request
> > > > > >>>>>>
> > > > > >>>>>> -------------------------
> > > > > >>>>>> Re: Chesnay
> > > > > >>>>>>
> > > > > >>>>>> The emeritus stuff seems like unnecessary noise.
> > > > > >>>>>> As Till mentioned, this is to make sure 2/3 majority is
> still
> > > > > feasible in
> > > > > >>>>>> practice.
> > > > > >>>>>>
> > > > > >>>>>> 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.
> > > > > >>>>>> That is a good suggestion. I am not familiar enough with the
> > > > > current Flink
> > > > > >>>>>> convention. Will you help on this? I saw you commented on
> some
> > > > part
> > > > > in the
> > > > > >>>>>> wiki. Are those complete?
> > > > > >>>>>>
> > > > > >>>>>> --------------------------
> > > > > >>>>>> Re: Aljoscha
> > > > > >>>>>>
> > > > > >>>>>> 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.
> > > > > >>>>>> Ha, you got me on this. The first version of the draft was
> > > almost
> > > > > identical
> > > > > >>>>>> to Kafka. But Robert has already caught a few inconsistent
> > > places.
> > > > > So it
> > > > > >>>>>> might still worth going through it to make sure we truly
> agree
> > > on
> > > > > them.
> > > > > >>>>>> Otherwise we may end up modifying them shortly after
> adoption.
> > > > > >>>>>>
> > > > > >>>>>>
> > > > > >>>>>> Thanks again folks, for all the valuable feedback. These are
> > > great
> > > > > >>>>>> discussion.
> > > > > >>>>>>
> > > > > >>>>>> Jiangjie (Becket) Qin
> > > > > >>>>>>
> > > > > >>>>>> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha Krettek <
> > > > > [hidden email]>
> > > > > >>>>>> wrote:
> > > > > >>>>>>
> > > > > >>>>>>> Big +1
> > > > > >>>>>>>
> > > > > >>>>>>> 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.
> > > > > >>>>>>>
> > > > > >>>>>>> Aljoscha
> > > > > >>>>>>>
> > > > > >>>>>>>> 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
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> [phone]
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>>
> > > > > >>>>>>>>>>> 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
> > > > > >>>>>>>>>>>
> > > > >
> > > > >
> > > >
> > >
> >
>

[Becket Qin]

Hi Hequn,

Thanks for sharing your thoughts. Please see the reply below:

> Perhaps what Jincheng means is to hold at least one PMC in the 3 binding
> votes? i.e, the vote could have 2 binding committers and 1 PMC.
> I think this makes sense considering a FLIP could somehow be a big feature
> which may impacts Flink a lot. Meanwhile, there is no loss of flexibility
> as committers also have a chance to vote and participate in it.
A few concerns of requiring a PMC vote in all FLIPs are the following:

1. Generally speaking, the PMC's primary responsibility is operating the
project and deciding what software to release on behalf of ASF. Committers,
on the other hand, are responsible for the technical part of the project.
So for FLIPs, a PMC's vote probably should not outweigh a committer's vote.
Besides, I am not sure whether a single PMCs +1 is really convincing enough
to decide whether the FLIP is good to go or not. Also, if some committers
have concern over a FLIP, they could just veto it. To me it is actually a
more strict requirement to pass a FLIP than asking a PMC to vote. In
practice, people will usually also address the concerns even if they are
not from a PMC/committer before they start the voting process. So I don't
see much benefit of requiring a PMC's vote in this case.

2. The at-least-one-PMC-vote requirement makes the votes no longer
independent. Ideally, a vote is either binding or non-binding by itself. If
we have the at-least-one-PMC-vote requirement here, imagine there have been
3 committers who voted +1. But the FLIP still has not passed, so those
votes are effectively non-binding. Now a PMC votes a +1, those votes
suddenly become binding, which is a little awkward.


The lazy 2/3 majority suggestion sounds reasonable to me. Some thoughts on
this:
1. One reason Hadoop uses lazy 2/3 majority is probably because there are
104 PMC members[1] for Hadoop which makes the 2/3 majority prohibitively
expensive. In our case, there are only 22 PMCs for Flink[2] and a quick
search shows at most 6 of them have not sent email in the recent 6 months
or so.

2. 2/3 majority votes are supposed to be very rare. It is designed in
particular for the cases that broad opinions are important, more
specifically new codebase adoption or modification to the bylaws. Therefore
such vote by its nature favors consensus over convenience. That means any
alternative voting type reducing the coverage worth a careful thinking.

3. I do agree that it does not make sense to have 2/3 majority if such
requirement is no-longer doable over time. But I am a little hesitant to
lower the threshold to lazy 2/3 majority in our case. What do you think
about doing the following:
    - After the voting started, there will be at least 6 days for people to
cast their votes.
    - After 6 days, if the result of the vote is still not determined, the
person who started the vote should reach out to the binding voters who have
not voted yet for at least 3 times and at least 7 days between each time.
If a binding voter still did not respond, the vote from that voter will be
excluded from the 2/3 majority counting.
This would ensure the coverage at our best effort while still let the 2/3
majority vote make progress.

Thanks,

Jiangjie (Becket) Qin


[1] https://projects.apache.org/committee.html?hadoop
[2] https://projects.apache.org/committee.html?flink

On Sun, Jul 21, 2019 at 1:39 PM Xu Forward <[hidden email]> wrote:

> Big +1 on this.
>
>
> best
>
> forward
>
> Hequn Cheng <[hidden email]> 于2019年7月21日周日 下午1:30写道：
>
> > Hi Becket,
> >
> > Big +1 on this.
> >
> > > Regarding the vote of FLIP, preferably at least includes a PMC vote.
> > Perhaps what Jincheng means is to hold at least one PMC in the 3 binding
> > votes? i.e, the vote could have 2 binding committers and 1 PMC.
> > I think this makes sense considering a FLIP could somehow be a big
> feature
> > which may impacts Flink a lot. Meanwhile, there is no loss of flexibility
> > as committers also have a chance to vote and participate in it.
> >
> > ========Seperator========
> >
> > For the nice bylaws, I agree with the general idea and most of the
> content.
> > Only share some thoughts about the "2/3 Majority". The main concern is I
> am
> > not sure if it is doable in practice. The reasons are:
> >
> > 1. If we follow the bylaws strictly, it means a committer or a PMC member
> > is active if he or she sends one email to the mailing list every 6
> months.
> > While the minimum length of the vote is only 6 days. There are chances
> that
> > during the vote, some of the active members are still offline of the
> > community.
> > 2. The code of Flink is changing fast and not everyone fully understands
> > every part. We don't need to force people to vote if they are not sure
> > about it. It may also make the final result less credible.
> >
> > Given the above reasons, perhaps we can change the 2/3 Majority to lazy
> 2/3
> > Majority, just as the Hadoop bylaws[1]. It makes a higher threshold,
> > however, more practical.
> >
> > What do you think?
> >
> > [1] https://hadoop.apache.org/bylaws.html
> >
> > On Sat, Jul 20, 2019 at 12:00 AM Becket Qin <[hidden email]>
> wrote:
> >
> > > Hi Jincheng,
> > >
> > > Thanks for the comments. I replied on the wiki page. Just a brief
> > summary,
> > > the current bylaws do require some of the FLIPs to get PMC approval if
> > > their impact is big enough. But it leaves majority of the technical
> > > decisions to the committers who are supposed to be responsible for
> making
> > > such decisions.
> > >
> > > Re: Robert,
> > >
> > > I agree we can simply remove the requirement of +1 from a non-author
> > > committer and revisit it in a bit. After all, it does not make sense to
> > > have a bylaw that we cannot afford. I have just updated the bylaws
> wiki.
> > >
> > > Thanks,
> > >
> > > Jiangjie (Becket) Qin
> > >
> > > On Fri, Jul 19, 2019 at 11:17 PM Robert Metzger <[hidden email]>
> > > wrote:
> > >
> > > > Hi all,
> > > > I agree with Aljoscha that trying to reflect the current status in
> the
> > > > bylaws, and then implementing changes one by one is a very involved
> > task.
> > > > Unless there's somebody who's really eager to drive this, I would
> stick
> > > to
> > > > Becket's initiative to come up with Bylaws for Flink, even if this
> > means
> > > > some changes.
> > > >
> > > > The cross-review requirement is the last big open point in this
> > > discussion.
> > > > It seems that a there is a slight tendency in the discussion that
> this
> > is
> > > > not feasible given the current pull request review situation.
> > > > For the sake of bringing this discussion to a conclusion, I'm fine
> with
> > > > leaving this requirement out. As we are currently adding more
> > committers
> > > to
> > > > the project, we might be able to revisit this discussion in 3 - 6
> > months.
> > > >
> > > >
> > > > On Thu, Jul 18, 2019 at 4:30 AM jincheng sun <
> [hidden email]
> > >
> > > > wrote:
> > > >
> > > > > Hi Becket,
> > > > >
> > > > > Thanks for the proposal.
> > > > >
> > > > > Regarding the vote of FLIP, preferably at least includes a PMC
> vote.
> > > > > Because FLIP is usually a big change or affects the user's
> interface
> > > > > changes. What do you think? (I leave the comment in the wiki.)
> > > > >
> > > > > Best,
> > > > > Jincheng
> > > > >
> > > > > Dawid Wysakowicz <[hidden email]> 于2019年7月17日周三 下午9:12写道：
> > > > >
> > > > > > Hi all,
> > > > > >
> > > > > > Sorry for joining late. I just wanted to say that I really like
> the
> > > > > > proposed bylaws!
> > > > > >
> > > > > > One comment, I also have the same concerns as expressed by few
> > people
> > > > > > before that the "committer +1" on code change might be hard to
> > > achieve
> > > > > > currently. On the other hand I would say this would be beneficial
> > for
> > > > > > the quality/uniformity of our codebase and knowledge sharing.
> > > > > >
> > > > > > I was just wondering what should be the next step for this? I
> think
> > > it
> > > > > > would make sense to already use those bylaws and put them to PMC
> > > vote.
> > > > > >
> > > > > > Best,
> > > > > >
> > > > > > Dawid
> > > > > >
> > > > > > On 12/07/2019 13:35, Piotr Nowojski wrote:
> > > > > > > Hi Aljoscha and Becket
> > > > > > >
> > > > > > > Right, 3 days for FLIP voting is fine I think.
> > > > > > >
> > > > > > >>> I’m missing this stated somewhere clearly. If we are stating
> > > that a
> > > > > > single
> > > > > > >>> committers +1 is good enough for code review, with 0 hours
> > delay
> > > > (de
> > > > > > facto
> > > > > > >>> the current state), we should also write down that this is
> > > subject
> > > > to
> > > > > > the
> > > > > > >>> best judgement of the committer to respect the components
> > > expertise
> > > > > and
> > > > > > >>> ongoing development plans (also the de facto current state).
> > > > > > >> Adding the statement would help clarify the intention, but it
> > may
> > > > be a
> > > > > > >> little difficult to enforce and follow..
> > > > > > > I would be fine with that, it’s a soft/vague rule anyway,
> > intended
> > > to
> > > > > be
> > > > > > used with your “best judgemenet". I would like to just avoid a
> > > > situation
> > > > > > when someone violates current uncodified state and refers to the
> > > bylaws
> > > > > > which are saying merging with any committer +1 is always fine
> (like
> > > > mine
> > > > > +1
> > > > > > for flink-python or flink-ml).
> > > > > > >
> > > > > > > Piotrek
> > > > > > >
> > > > > > >> On 12 Jul 2019, at 11:29, Aljoscha Krettek <
> [hidden email]
> > >
> > > > > wrote:
> > > > > > >>
> > > > > > >> @Piotr regarding the 3 days voting on the FLIP. This is just
> > about
> > > > the
> > > > > > voting, before that there needs to be the discussion thread. If
> > three
> > > > > days
> > > > > > have passed on a vote and there is consensus (i.e. 3
> > committers/PMCs
> > > > have
> > > > > > voted +1) that seems a high enough bar for me. So far, we have
> > rarely
> > > > see
> > > > > > any FLIPs pass that formal bar.
> > > > > > >>
> > > > > > >> According to the recent META-FLIP thread, we want to use "lazy
> > > > > > majority" for the FLIP voting process. I think that should be
> > changed
> > > > > from
> > > > > > “consensus” in the proposed bylaws.
> > > > > > >>
> > > > > > >> Regarding the current state: do we have a current state that
> we
> > > all
> > > > > > agree on? I have the feeling that if we try to come up with
> > something
> > > > > that
> > > > > > reflects the common state, according to PMCs/commiters, that
> might
> > > > take a
> > > > > > very long time. In that case I think it’s better to adopt
> something
> > > > that
> > > > > we
> > > > > > all like, rather than trying to capture how we do it now.
> > > > > > >>
> > > > > > >> Aljoscha
> > > > > > >>
> > > > > > >>> On 12. Jul 2019, at 11:07, Piotr Nowojski <
> [hidden email]
> > >
> > > > > wrote:
> > > > > > >>>
> > > > > > >>> Hi,
> > > > > > >>>
> > > > > > >>> Thanks for the proposal. Generally speaking +1 from my side
> to
> > > the
> > > > > > general idea and most of the content. I also see merit to the
> > > Chesney's
> > > > > > proposal to start from the current state. I think either would be
> > > fine
> > > > > for
> > > > > > me.
> > > > > > >>>
> > > > > > >>> Couple of comments:
> > > > > > >>>
> > > > > > >>> 1.
> > > > > > >>>
> > > > > > >>> I also think that requiring +1 from another committer would
> > slow
> > > > down
> > > > > > and put even more strain on the current reviewing bottleneck that
> > we
> > > > are
> > > > > > having. Even if the change clear and simple, context switch cost
> is
> > > > quite
> > > > > > high, and that’s just one less PR that the second “cross”
> committer
> > > > could
> > > > > > have reviewed somewhere else in that time. Besides, current setup
> > > that
> > > > we
> > > > > > have (with no cross +1 from another committer required) works
> quite
> > > > well
> > > > > > and I do not feel that’s causing troubles. On the other hand
> > > reviewing
> > > > > > bottleneck is.
> > > > > > >>>
> > > > > > >>> 2.
> > > > > > >>>
> > > > > > >>>> I think a committer should know when to ask another
> committer
> > > for
> > > > > > feedback or not.
> > > > > > >>> I’m missing this stated somewhere clearly. If we are stating
> > > that a
> > > > > > single committers +1 is good enough for code review, with 0 hours
> > > delay
> > > > > (de
> > > > > > facto the current state), we should also write down that this is
> > > > subject
> > > > > to
> > > > > > the best judgement of the committer to respect the components
> > > expertise
> > > > > and
> > > > > > ongoing development plans (also the de facto current state).
> > > > > > >>>
> > > > > > >>> 3.
> > > > > > >>>
> > > > > > >>> Minimum length of 3 days for FLIP I think currently might be
> > > > > > problematic/too quick and can lead to problems if respected to
> the
> > > > > letter.
> > > > > > Again I think it depends highly on whether the committers with
> > > highest
> > > > > > expertise in the affected components managed to respond or not.
> > > > > > >>>
> > > > > > >>> Piotrek
> > > > > > >>>
> > > > > > >>>> On 12 Jul 2019, at 09:42, Chesnay Schepler <
> > [hidden email]>
> > > > > > wrote:
> > > > > > >>>>
> > > > > > >>>> I'm wondering whether we shouldn't first write down Bylaws
> > that
> > > > > > reflect the current state, and then have separate discussions for
> > > > > > individual amendments. My gut feeling is that this discussion
> will
> > > > > quickly
> > > > > > become a chaotic mess with plenty points being discussed at once.
> > > > > > >>>>
> > > > > > >>>> On 11/07/2019 20:03, Bowen Li wrote:
> > > > > > >>>>> On Thu, Jul 11, 2019 at 10:38 AM Becket Qin <
> > > > [hidden email]>
> > > > > > wrote:
> > > > > > >>>>>
> > > > > > >>>>>> Thanks everyone for all the comments and feedback. Please
> > see
> > > > the
> > > > > > replies
> > > > > > >>>>>> below:
> > > > > > >>>>>>
> > > > > > >>>>>> --------------------------------
> > > > > > >>>>>> Re: Konstantin
> > > > > > >>>>>>
> > > > > > >>>>>>> * 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.
> > > > > > >>>>>> Good point. Just added the entry.
> > > > > > >>>>>>
> > > > > > >>>>>> -------------------------------
> > > > > > >>>>>> Re: Konstantin
> > > > > > >>>>>>
> > > > > > >>>>>>> * 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.
> > > > > > >>>>>> & Re: Till
> > > > > > >>>>>>
> > > > > > >>>>>>> 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.
> > > > > > >>>>>> I am with Robert and Aljoscha on this.
> > > > > > >>>>>>
> > > > > > >>>>>> I completely understand the concern here. TBH, in Kafka
> > > > > occasionally
> > > > > > >>>>>> trivial patches from committers are still merged without
> > > > following
> > > > > > the
> > > > > > >>>>>> cross-review requirement, but it is rare. That said, I
> still
> > > > think
> > > > > > an
> > > > > > >>>>>> additional committer's review makes sense due to the
> > following
> > > > > > reasons:
> > > > > > >>>>>> 1. The bottom line here is that we need to make sure every
> > > patch
> > > > > is
> > > > > > >>>>>> reviewed with a high quality. This is a little difficult
> to
> > > > > > guarantee if
> > > > > > >>>>>> the review comes from a contributor for many reasons. In
> > some
> > > > > > cases, a
> > > > > > >>>>>> contributor may not have enough knowledge about the
> project
> > to
> > > > > make
> > > > > > a good
> > > > > > >>>>>> judgement. Also sometimes the contributors are more
> eagerly
> > to
> > > > > get a
> > > > > > >>>>>> particular issue fixed, so they are willing to lower the
> > > review
> > > > > bar.
> > > > > > >>>>>> 2. One byproduct of such cross review among committers,
> > which
> > > I
> > > > > > personally
> > > > > > >>>>>> feel useful, is that it helps gradually form consistent
> > design
> > > > > > principles
> > > > > > >>>>>> and code style. This is because the committers will know
> how
> > > the
> > > > > > other
> > > > > > >>>>>> committers are writing code and learn from each other. So
> > they
> > > > > tend
> > > > > > to
> > > > > > >>>>>> reach some tacit understanding on how things should be
> done
> > in
> > > > > > general.
> > > > > > >>>>>>
> > > > > > >>>>>> Another way to think about this is to consider the
> following
> > > two
> > > > > > scenarios:
> > > > > > >>>>>> 1. Reviewing a committer's patch takes a lot of
> iterations.
> > > Then
> > > > > > the patch
> > > > > > >>>>>> needs to be reviewed even if it takes time because there
> are
> > > > > things
> > > > > > >>>>>> actually needs to be clarified / changed.
> > > > > > >>>>>> 2. Reviewing a committer's patch is very smooth and quick,
> > so
> > > > the
> > > > > > patch is
> > > > > > >>>>>> merged soon. Then reviewing such a patch does not take
> much
> > > > time.
> > > > > > >>>>>>
> > > > > > >>>>>> Letting another committer review the patch from a
> committer
> > > > falls
> > > > > > either in
> > > > > > >>>>>> case 1 or case 2. The best option here is to review the
> > patch
> > > > > > because
> > > > > > >>>>>> If it is case 1, the patch actually needs to be reviewed.
> > > > > > >>>>>> If it is case 2, the review should not take much time
> > anyways.
> > > > > > >>>>>>
> > > > > > >>>>>> In the contrast, we will risk encounter case 1 if we skip
> > the
> > > > > > cross-review.
> > > > > > >>>>>>
> > > > > > >>>>>> ------------------------
> > > > > > >>>>>> Re: Robert
> > > > > > >>>>>>
> > > > > > >>>>>> I replied to your comments in the wiki and made the
> > following
> > > > > > modifications
> > > > > > >>>>>> to resolve some of your comments:
> > > > > > >>>>>> 1. Added a release manager role section.
> > > > > > >>>>>> 2. changed the name of "lazy consensus" to "consensus" to
> > > align
> > > > > with
> > > > > > >>>>>> general definition of Apache glossary and other projects.
> > > > > > >>>>>> 3. review board  -> pull request
> > > > > > >>>>>>
> > > > > > >>>>>> -------------------------
> > > > > > >>>>>> Re: Chesnay
> > > > > > >>>>>>
> > > > > > >>>>>> The emeritus stuff seems like unnecessary noise.
> > > > > > >>>>>> As Till mentioned, this is to make sure 2/3 majority is
> > still
> > > > > > feasible in
> > > > > > >>>>>> practice.
> > > > > > >>>>>>
> > > > > > >>>>>> 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.
> > > > > > >>>>>> That is a good suggestion. I am not familiar enough with
> the
> > > > > > current Flink
> > > > > > >>>>>> convention. Will you help on this? I saw you commented on
> > some
> > > > > part
> > > > > > in the
> > > > > > >>>>>> wiki. Are those complete?
> > > > > > >>>>>>
> > > > > > >>>>>> --------------------------
> > > > > > >>>>>> Re: Aljoscha
> > > > > > >>>>>>
> > > > > > >>>>>> 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.
> > > > > > >>>>>> Ha, you got me on this. The first version of the draft was
> > > > almost
> > > > > > identical
> > > > > > >>>>>> to Kafka. But Robert has already caught a few inconsistent
> > > > places.
> > > > > > So it
> > > > > > >>>>>> might still worth going through it to make sure we truly
> > agree
> > > > on
> > > > > > them.
> > > > > > >>>>>> Otherwise we may end up modifying them shortly after
> > adoption.
> > > > > > >>>>>>
> > > > > > >>>>>>
> > > > > > >>>>>> Thanks again folks, for all the valuable feedback. These
> are
> > > > great
> > > > > > >>>>>> discussion.
> > > > > > >>>>>>
> > > > > > >>>>>> Jiangjie (Becket) Qin
> > > > > > >>>>>>
> > > > > > >>>>>> On Thu, Jul 11, 2019 at 9:55 PM Aljoscha Krettek <
> > > > > > [hidden email]>
> > > > > > >>>>>> wrote:
> > > > > > >>>>>>
> > > > > > >>>>>>> Big +1
> > > > > > >>>>>>>
> > > > > > >>>>>>> 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.
> > > > > > >>>>>>>
> > > > > > >>>>>>> Aljoscha
> > > > > > >>>>>>>
> > > > > > >>>>>>>> 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
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> [phone]
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>>
> > > > > > >>>>>>>>>>> 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
> > > > > > >>>>>>>>>>>
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>