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 <fhue...@gmail.com> 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 <becket....@gmail.com >>> : >> >>> 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 <se...@apache.org> 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 <fhue...@gmail.com> >> 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 < >>>>> becket....@gmail.com >>>>>> : >>>>> >>>>>> 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 <car...@gmail.com> 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 <becket....@gmail.com> >>>> 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 priv...@flink.apache.org. >>>>>>>> 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 < >>> becket....@gmail.com> >>>>>>> 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 < >>>> fhue...@gmail.com> >>>>>>>> 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 < >>>>>>>>>> becket....@gmail.com >>>>>>>>>>> : >>>>>>>>>> >>>>>>>>>>> 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 < >>>>>> forwardxu...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>>> Big +1 on this. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> best >>>>>>>>>>>> >>>>>>>>>>>> forward >>>>>>>>>>>> >>>>>>>>>>>> Hequn Cheng <chenghe...@gmail.com> 于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 < >>>>>>> becket....@gmail.com >>>>>>>>> >>>>>>>>>>>> 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 < >>>>>>>>>> rmetz...@apache.org >>>>>>>>>>>> >>>>>>>>>>>>>> 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 < >>>>>>>>>>>> sunjincheng...@gmail.com >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 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 <dwysakow...@apache.org> >>>>> 于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 >> < >>>>>>>>>>>> aljos...@apache.org >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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 >> < >>>>>>>>>>>> pi...@ververica.com >>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 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 >>> < >>>>>>>>>>>>> ches...@apache.org> >>>>>>>>>>>>>>>>> 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 >>>> < >>>>>>>>>>>>>>> becket....@gmail.com> >>>>>>>>>>>>>>>>> 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 >>>>>>> < >>>>>>>>>>>>>>>>> aljos...@apache.org> >>>>>>>>>>>>>>>>>>>>>>> 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 >>>> < >>>>>>>>>>>>>>> trohrm...@apache.org> >>>>>>>>>>>>>>>>> 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 >>>>>>>> < >>>>>>>>>>>>>>>>> ches...@apache.org> >>>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>> < >>>>>>>>>>>>>>>>>>>>>>>>>> konstan...@ververica.com> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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 < >>>>>>>>>>>>>>>>> becket....@gmail.com> >>>>>>>>>>>>>>>>>>>>>>>>>> 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 >>>>>>>>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
