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