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