http://deprecated-apache-flink-mailing-list-archive.368.s1.nabble.com/DISCUSS-Flink-project-bylaws-tp30409p30468.html
> 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
> > >>>>
> > >>>> +49 160 91394525
> > >>>>
> > >>>>
> > >>>> Planned Absences: 10.08.2019 - 31.08.2019, 05.09. - 06.09.2010
> > >>>>
> > >>>>
> > >>>> --
> > >>>>
> > >>>> Ververica GmbH | Invalidenstrasse 115, 10115 Berlin, Germany
> > >>>>
> > >>>> --
> > >>>>
> > >>>> Ververica GmbH
> > >>>> Registered at Amtsgericht Charlottenburg: HRB 158244 B
> > >>>> Managing Directors: Dr. Kostas Tzoumas, Dr. Stephan Ewen
> > >>>>
> > >>
> > >>
> >
> >
>