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