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