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