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 <m...@apache.org> 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 <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 > >>>>>>>>>>>>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > >
