http://deprecated-apache-flink-mailing-list-archive.368.s1.nabble.com/DISCUSS-Flink-project-bylaws-tp30409p32317.html
> Thanks a lot for running the vote Becket!
>
> I have removed the "(draft)" from the wiki page :)
> Should we link the bylaws also from the Flink website?
>
>
> On Thu, Aug 22, 2019 at 6:23 PM Becket Qin <
[hidden email]> wrote:
>
>> Thanks for collecting the ideas of Bylaws changes. It is a good idea!
>>
>> Jiangjie (Becket) Qin
>>
>> On Thu, Aug 22, 2019 at 12:11 PM Robert Metzger <
[hidden email]>
>> wrote:
>>
>>> I have started a Wiki page (editable by all) for collecting ideas for
>>> Bylaws changes, so that we can batch changes together and then vote on
>>> them:
>>>
>>
https://cwiki.apache.org/confluence/display/FLINK/Ideas+for+Bylaw+changes>>> On Tue, Aug 13, 2019 at 1:41 PM Becket Qin <
[hidden email]> wrote:
>>>
>>>> Hi Robert,
>>>>
>>>> Thanks for help apply the changes. I agree we should freeze the change
>> to
>>>> the bylaws page starting from now. For this particular addition of
>>>> clarification, I'll send a notice in the voting thread to let who have
>>>> already voted to know.
>>>>
>>>> Thanks,
>>>>
>>>> Jiangjie (Becket) Qin
>>>>
>>>> On Tue, Aug 13, 2019 at 1:29 PM Robert Metzger <
[hidden email]>
>>>> wrote:
>>>>
>>>>> Hi Becket,
>>>>> I've applied the proposed change to the document:
>>>>>
>>>>>
>>
https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=120731026&selectedPageVersions=20&selectedPageVersions=19>>>>> I would propose to stop accepting changes to the document now, as it
>>>> might
>>>>> start a discussion about the validity of the vote and the bylaws
>>> itself.
>>>>> Changes to the document require a 2/3 majority.
>>>>>
>>>>>
>>>>> On Tue, Aug 13, 2019 at 12:20 PM Maximilian Michels <
[hidden email]>
>>>>> wrote:
>>>>>
>>>>>> Hi Becket,
>>>>>>
>>>>>> Thanks for clarifying and updating the draft. The changes look good
>>> to
>>>>> me.
>>>>>> I don't feel strong about a 2/3 majority in case of committer/PMC
>>>>>> removal. Like you pointed out, both provide a significant hurdle
>> due
>>> to
>>>>>> possible vetos or a 2/3 majority.
>>>>>>
>>>>>> Thanks,
>>>>>> Max
>>>>>>
>>>>>> On 13.08.19 10:36, Becket Qin wrote:
>>>>>>> Piotr just reminded me that there was a previous suggestion to
>>>> clarify
>>>>> a
>>>>>>> committer's responsibility when commit his/her own patch. So I'd
>>> like
>>>>> to
>>>>>>> incorporate that in the bylaws. The additional clarification is
>>>>> following
>>>>>>> in bold and italic font.
>>>>>>>
>>>>>>> one +1 from a committer followed by a Lazy approval (not counting
>>> the
>>>>>> vote
>>>>>>>> of the contributor), moving to lazy majority if a -1 is
>> received.
>>>>>>>
>>>>>>> Note that this implies that committers can +1 their own commits
>> and
>>>>> merge
>>>>>>>> right away. *However, the committe**rs should use their best
>>>> judgement
>>>>>> to
>>>>>>>> respect the components expertise and ongoing development plan.*
>>>>>>>
>>>>>>> This does not really change any of the existing bylaws, just
>> about
>>>>>>> clarification.
>>>>>>>
>>>>>>> If there is no objection to this additional clarification, after
>>> the
>>>>>> bylaws
>>>>>>> wiki is updated, I'll send an update notice to the voting thread
>> to
>>>>>> inform
>>>>>>> those who already voted about this addition.
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Jiangjie (Becket) Qin
>>>>>>>
>>>>>>> On Mon, Aug 12, 2019 at 11:19 AM Becket Qin <
>>
[hidden email]>
>>>>>> wrote:
>>>>>>>> Hi Maximillian,
>>>>>>>>
>>>>>>>> Thanks for the feedback. Please see the reply below:
>>>>>>>>
>>>>>>>> Step 2 should include a personal email to the PMC members in
>>>> question.
>>>>>>>> I'm afraid reminders inside the vote thread could be overlooked
>>>>> easily.
>>>>>>>>
>>>>>>>> This is exactly what I meant to say by "reach out" :) I just
>> made
>>> it
>>>>>> more
>>>>>>>> explicit.
>>>>>>>>
>>>>>>>> The way the terms are described in the draft, the consensus is
>>>> "lazy",
>>>>>>>>> i.e. requires only 3 binding votes. I'd suggest renaming it to
>>>> "Lazy
>>>>>>>>> Consensus". This is in line with the other definitions such as
>>>> "Lazy
>>>>>>>>> Majority".
>>>>>>>> It was initially called "lazy consensus", but Robert pointed out
>>>> that
>>>>>>>> "lazy consensus" actually means something different in ASF term
>>> [1].
>>>>>>>> Here "lazy" pretty much means "assume everyone is +1 unless
>>> someone
>>>>> says
>>>>>>>> otherwise". This means any vote that requires a minimum number
>> of
>>> +1
>>>>> is
>>>>>> not
>>>>>>>> really a "lazy" vote.
>>>>>>>>
>>>>>>>> Removing a committer / PMC member only requires 3 binding votes.
>>> I'd
>>>>>>>>> expect an important action like this to require a 2/3 majority.
>>>>>>>> Personally I think consensus is good enough here. PMC members
>> can
>>>>> cast a
>>>>>>>> veto if they disagree about the removal. In some sense, it is
>> more
>>>>>>>> difficult than with 2/3 majority to remove a committer / PMC
>>> member.
>>>>>> Also,
>>>>>>>> it might be a hard decision for some PMC members if they have
>>> never
>>>>>> worked
>>>>>>>> with the person in question. That said, I am OK to change it to
>>> 2/3
>>>>>>>> majority as this will happen very rarely.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>
>>>>>>>> [1]
https://www.apache.org/foundation/voting.html#LazyConsensus>>>>>>>>
>>>>>>>> On Sun, Aug 11, 2019 at 5:00 PM Maximilian Michels <
>>>
[hidden email]>
>>>>>> wrote:
>>>>>>>>> I'm a bit late to the discussion here. Three suggestions:
>>>>>>>>>
>>>>>>>>> 1) Procedure for "insufficient active binding voters to reach
>> 2/3
>>>>>> majority
>>>>>>>>>> 1. Wait until the minimum length of the voting passes.
>>>>>>>>>> 2. Publicly reach out to the remaining binding voters in
>> the
>>>>>> voting
>>>>>>>>> mail thread for at least 2 attempts with at least 7 days
>> between
>>>> two
>>>>>>>>> attempts.
>>>>>>>>>> 3. If the binding voter being contacted still failed to
>>>> respond
>>>>>>>>> after all the attempts, the binding voter will be considered as
>>>>>> inactive
>>>>>>>>> for the purpose of this particular voting.
>>>>>>>>>
>>>>>>>>> Step 2 should include a personal email to the PMC members in
>>>>> question.
>>>>>>>>> I'm afraid reminders inside the vote thread could be overlooked
>>>>> easily.
>>>>>>>>> 2) "Consensus" => "Lazy Consensus"
>>>>>>>>>
>>>>>>>>> The way the terms are described in the draft, the consensus is
>>>>> "lazy",
>>>>>>>>> i.e. requires only 3 binding votes. I'd suggest renaming it to
>>>> "Lazy
>>>>>>>>> Consensus". This is in line with the other definitions such as
>>>> "Lazy
>>>>>>>>> Majority".
>>>>>>>>>
>>>>>>>>> 3) Committer / PMC Removal
>>>>>>>>>
>>>>>>>>> Removing a committer / PMC member only requires 3 binding
>> votes.
>>>> I'd
>>>>>>>>> expect an important action like this to require a 2/3 majority.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Do you think we could incorporate those suggestions?
>>>>>>>>>
>>>>>>>>> Thanks,
>>>>>>>>> Max
>>>>>>>>>
>>>>>>>>> On 11.08.19 10:14, Becket Qin wrote:
>>>>>>>>>> Hi folks,
>>>>>>>>>>
>>>>>>>>>> Thanks for all the discussion and support. I have started the
>>>> voting
>>>>>>>>> thread.
>>>>>>>>>>
>>
http://apache-flink-mailing-list-archive.1008284.n3.nabble.com/VOTE-Flink-Project-Bylaws-td31558.html>>>>>>>>>> Thanks,
>>>>>>>>>>
>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>
>>>>>>>>>> On Thu, Aug 8, 2019 at 2:56 PM Fabian Hueske <
>>
[hidden email]
>>>>>> wrote:
>>>>>>>>>>> Thanks for the update and driving the discussion Becket!
>>>>>>>>>>> +1 for starting a vote.
>>>>>>>>>>>
>>>>>>>>>>> Am Mi., 7. Aug. 2019 um 11:44 Uhr schrieb Becket Qin <
>>>>>>>>>
[hidden email]
>>>>>>>>>>>> :
>>>>>>>>>>>> Thanks Stephan.
>>>>>>>>>>>>
>>>>>>>>>>>> I think we have resolved all the comments on the wiki page.
>>>> There
>>>>>> are
>>>>>>>>> two
>>>>>>>>>>>> minor changes made to the bylaws since last week.
>>>>>>>>>>>> 1. For 2/3 majority, the required attempts to reach out to
>>>> binding
>>>>>>>>> voters
>>>>>>>>>>>> is reduced from 3 to 2. This helps shorten the voting
>> process
>>> a
>>>>>> little
>>>>>>>>>>> bit.
>>>>>>>>>>>> 2. Clarified what is considered as the adoption of new
>>> codebase.
>>>>>>>>>>>> I think we almost reached consensus. I'll start a voting
>>> thread
>>>> in
>>>>>> two
>>>>>>>>>>> days
>>>>>>>>>>>> if there is no new concerns.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>
>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Aug 5, 2019 at 1:09 PM Stephan Ewen <
>>
[hidden email]
>>>>>> wrote:
>>>>>>>>>>>>> I added a clarification to the table, clarifying that the
>>>> current
>>>>>>>>>>>> phrasing
>>>>>>>>>>>>> means that committers do not need another +1 for their
>>> commits.
>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 2:11 PM Fabian Hueske <
>>>>
[hidden email]
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Hi Becket,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks a lot for pushing this forward and addressing the
>>>>> feedback.
>>>>>>>>>>>>>> I'm very happy with the current state of the bylaws.
>>>>>>>>>>>>>> +1 to wait until Friday before starting a vote.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Best, Fabian
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am Mo., 29. Juli 2019 um 13:47 Uhr schrieb Becket Qin <
>>>>>>>>>>>>>>
[hidden email]
>>>>>>>>>>>>>>> :
>>>>>>>>>>>>>>> Hi Everyone,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks for all the discussion and feedback.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>> start a voting thread after that.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Jiangjie (Becket) Qin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Fri, Jul 26, 2019 at 6:49 PM Yu Li <
[hidden email]>
>>>>> wrote:
>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>