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