http://deprecated-apache-flink-mailing-list-archive.368.s1.nabble.com/DISCUSS-Flink-project-bylaws-tp30409p30771.html
Thanks for the comments. I replied on the wiki page. Just a brief summary,
their impact is big enough. But it leaves majority of the technical
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.
> 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
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> +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
> > > >>>>>>>>>>>
> > >
> > >
> >
>