http://deprecated-apache-flink-mailing-list-archive.368.s1.nabble.com/DISCUSS-Flink-project-bylaws-tp30409p31098.html
It seems that we have almost reached consensus. I'll leave the discussion
thread open until this Friday. If there is no more concerns raised, I'll
> Hi Becket,
>
> Thanks for noticing and resolving my comment around PMC removal and ASF
> rules of PMC membership change process, which you seem to neglect in the
> summary of updates (smile).
>
> Best Regards,
> Yu
>
>
> On Wed, 24 Jul 2019 at 04:32, Becket Qin <
[hidden email]> wrote:
>
> > Hi folks,
> >
> > Thanks for all the feedback.
> >
> > It seems that there are a few concerns over the emeritus status after 6
> > months of inactivity. Given that the main purpose is just to make sure
> 2/3
> > majority can pass and we sort of have a solution for that, I just updated
> > the draft with the following changes:
> >
> > 1. Removed the inactivity term for emeritus committers / PMCs. A
> committer
> > / PMC will only be considered emeritus by their own claim.
> > 2. Removed the approval process for reinstatement of the emeritus
> > committers / PMCs. An emeritus committer / PMC will be reinstated when
> they
> > send an email to the
[hidden email].
> > 3. Adde the term to ensure 2/3 majority voting is still doable when there
> > are non-emeritus committers / PMCs who do not cast the vote.
> >
> > Please let me know if you have any further thoughts.
> >
> > Thanks,
> >
> > Jiangjie (Becket) Qin
> >
> > On Tue, Jul 23, 2019 at 10:18 AM Becket Qin <
[hidden email]>
> wrote:
> >
> > > Hi Fabian,
> > >
> > > Thanks for the feedback.
> > >
> > > I agree that if we don't like emeritus committers / PMCs, we don't have
> > to
> > > do it. That said, emeritus status simply means whether an individual is
> > > active / inactive in the community. It does not make the merits earned
> to
> > > go away. For our purpose, emeritus status is mostly just a way to make
> > 2/3
> > > majority possible. As you noticed, since reaching out to binding voters
> > who
> > > have not voted can achieve the same goal, the emeritus status is more
> of
> > an
> > > optimization so we don't have to ping the inactive binding voters every
> > > time and wait for long. However, given that 2/3 majority votings are
> > rare,
> > > such communication cost is probably OK. So I think we can remove that
> > > emeritus part from the bylaws.
> > >
> > > 1) We should add to the requirements of the PMC that they need to make
> > >> sure the project complies with brand issues and reports misuse of ASF
> > >> brands.
> > >
> > > Good point. Added.
> > >
> > > 2) Do we want to restrict voting days to working days, i.e., a 3 day
> vote
> > >> that starts on Friday 11:00am ends on Wednesday 11:00am?
> > >
> > > This might be a little tricky because people are from countries in
> > > different time zones and with different holidays, and so on. If we are
> > > worrying about 3 days minimum length is not enough for those who want
> to
> > > give feedback, we can make it 5 days.
> > >
> > > 3) Do we need a process do decide about removal of features (like the
> > >> DataSet API for instance or the legacy DataSet/DataStream Python
> APIs)?
> > >
> > > I assume such action should be covered by FLIP as it is a change to the
> > > API and probably needs a migration plan. It would be useful to have a
> > > formal deprecation procedure. But that might be better to be put into
> > > somewhere else because the bylaws are primarily focusing on the
> > > non-technical rules, whereas the deprecation seems more on the
> technical
> > > side.
> > >
> > > Thanks,
> > >
> > > Jiangjie (Becket) Qin
> > >
> > > On Mon, Jul 22, 2019 at 11:42 PM Fabian Hueske <
[hidden email]>
> > wrote:
> > >
> > >> Hi all,
> > >>
> > >> First of all thank you very much Becket for starting this discussion!
> > >> I think it is a very good idea and overdue to formally define some of
> > our
> > >> community processes.
> > >>
> > >> Similar to Chesnay, I have concerns about the distinction between
> active
> > >> and non-active / emeritus committers and PMC members.
> > >> My foremost concern is that this is not in the spirit of the Apache
> Way
> > >> [1]
> > >> which is (among other things) based on the idea of merit which once
> > >> earned,
> > >> does not go away over time.
> > >> I know other projects like Hadoop and Kafka have similar clauses in
> the
> > >> bylaws but IMO we don't need to adopt them if we don't like them.
> > >> For example, I don't like the idea that committers or PMC members who
> > are
> > >> temporarily away from the project (for whatever reason: parental
> leave,
> > >> sabbatical, health issues, etc.) need the PMC approval to be "active"
> > >> again.
> > >> As far as I am aware, we have not seen any issues with inactive
> members
> > in
> > >> the past.
> > >> Moreover, it would be hard to track whether somebody became inactive
> at
> > >> some point in time (which we would need to do, if I understand the
> > >> proposal
> > >> correctly).
> > >> With the approach that Becket suggested in his last email (reaching
> out
> > to
> > >> binding voters who haven't voted yet), we could drop the distinction
> > >> between active and non-active committers and PMC members.
> > >>
> > >> I also have a few minor comments:
> > >>
> > >> 1) We should add to the requirements of the PMC [2] that they need to
> > make
> > >> sure the project complies with brand issues and reports misuse of ASF
> > >> brands.
> > >> 2) Do we want to restrict voting days to working days, i.e., a 3 day
> > vote
> > >> that starts on Friday 11:00am ends on Wednesday 11:00am?
> > >> 3) Do we need a process do decide about removal of features (like the
> > >> DataSet API for instance or the legacy DataSet/DataStream Python
> APIs)?
> > >>
> > >> Thank you,
> > >> Fabian
> > >>
> > >> [1]
https://www.apache.org/theapacheway/> > >> [2]
https://www.apache.org/dev/pmc.html> > >>
> > >> Am So., 21. Juli 2019 um 13:22 Uhr schrieb Becket Qin <
> > >>
[hidden email]
> > >> >:
> > >>
> > >> > 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
> > >> > > > > > > > >>>>>>>>>>>
> > >> > > > > > > > >>>>>>>>>>> +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
> > >> > > > > > > > >>>>>>>>>>>
> > >> > > > > > > >
> > >> > > > > > > >
> > >> > > > > > >
> > >> > > > > >
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> > >
> >
>