Thanks for bring up this discussion Jan! +1 for cearly define BIP for beam.
And I think would be nice to initialize a concept document for BIP. Just a reminder: the document may contains: - How many kinds of improvement in beam. - What kind of improvement should to create a BIP. - What should be included in a BIP. - Who can create the BIP. - Who can participate in the discussion of BIP and who can vote for BIP. - What are the possible limitations of BiP, such as whether it is necessary to complete the dev of BIP in one release. - How to track a BIP. Here is a question: I found out a policy[1] in beam, but only contains the poilcy of release , my question is does beam have something called Bylaws? Similar as Flink[1]. Anyway, I like your proposals Jan :) Best, Jincheng [1] https://beam.apache.org/community/policies/ [2] https://cwiki.apache.org/confluence/display/FLINK/Flink+Bylaws#FlinkBylaws-Approvals David Morávek <[email protected]> 于2019年12月10日周二 下午2:33写道： > Hi Jan, > > I think this is more pretty much what we currently do, just a little bit > more transparent for the community. If the process is standardized, it can > open doors for bigger contributions from people not familiar with the > process. Also it's way easier to track progress of BIPs, than documents > linked from the mailing list. > > Big +1 ;) > > D. > > On Sun, Dec 8, 2019 at 12:42 PM Jan Lukavský <[email protected]> wrote: > >> Hi, >> >> I'd like to revive a discussion that was taken some year and a half ago >> [1], which included a concept of "BIP" (Beam Improvement Proposal) - an >> equivalent of "FLIP" (flink), "KIP" (kafka), "SPIP" (spark), and so on. >> >> The discussion then ended without any (public) conclusion, so I'd like >> to pick up from there. There were questions related to: >> >> a) how does the concept of BIP differ from simple plain JIRA? >> >> b) what does it bring to the community? >> >> I'd like to outline my point of view on both of these aspects (they are >> related). >> >> BIP differs from JIRA by definition of a process: >> >> BIP -> vote -> consensus -> JIRA -> implementation >> >> This process (although it might seem a little unnecessary formal) brings >> the following benefits: >> >> i) improves community's overall awareness of planned and in-progress >> features >> >> ii) makes it possible to prioritize long-term goals (create "roadmap" >> that was mentioned in the referred thread) >> >> iii) by casting explicit vote on each improvement proposal diminishes >> the probability of wasted work - as opposed to our current state, where >> it is hard to tell when there is a consensus and what actions need to be >> done in order to reach one if there isn't >> >> iv) BIPs that eventually pass a vote can be regarded as "to be >> included in some short term" and so new BIPs can build upon them, >> without the risk of having to be redefined if their dependency for >> whatever reason don't make it to the implementation >> >> Although this "process" might look rigid and corporate, it actually >> brings better transparency and overall community health. This is >> especially important as the community grows and becomes more and more >> distributed. There are many, many open questions in this proposal that >> need to be clarified, my current intent is to grab a grasp about how the >> community feels about this. >> >> Looking forward to any comments, >> >> Jan >> >> [1] >> >> https://lists.apache.org/thread.html/4e1fffa2fde8e750c6d769bf4335853ad05b360b8bd248ad119cc185%40%3Cdev.beam.apache.org%3E >> >>
