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 > > > >> > > > > > > > >>>>>>>>>>> > > > >> > > > > > > > > > > >> > > > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > >> > > > > > >> > > > > >> > > > > > > > > > >
