Additional process is a two-edged sword: it can help move stuff forward, to the correct decision, but it can also add significant overhead.
I think there are many proposals for which the existing processes of deriving consensus (over email, possibly followed by a formal vote or lazy consensus) are sufficient. However, sometimes they're not. Specifically, for long-term roadmaps, it would be useful to have them in a standard place that can be tracked and understood (I don't think we've been able to use JIRA effectively for this here). I also think there are some proposals that reach a certain level of complexity that trying to address them by occasionally responding to email threads as they come up is insufficient. For these latter, I think there is a need for commitment for a group of people in the community to commit to clearly defining and driving a solution to the problem via a more formal process. Often the one making the proposal has sufficient motivation, but sometimes what lacks is be (non-sporadic) investment by those trying to understand, evaluate, and incorporate the proposal. So I'm (strongly) +1 for exploring a more formal process, but -1 on requiring it. On Sun, Dec 15, 2019 at 1:07 AM Jan Lukavský <je...@seznam.cz> wrote: > > Hi, > > thanks for reactions so far. I agree that there are many questions that have > to be clarified. I'd propose to split this into two parts: > > a) first reach a consensus that we want this process in the first place > > b) after that, we need to clarify all the details - that will probably be > somewhat iterative procedure > > I'm not sure if there is something more we need to clarify before we can cast > a vote on (a). > > Thoughts? > > Jan > > On 12/10/19 3:46 PM, Łukasz Gajowy wrote: > > +1 for formalizing the process, enhancing it and documenting clearly. > > I noticed that Apache Airflow has a cool way of both creating AIPs and > keeping track of all of them. There is a "Create new AIP" button on their > Confluence. This way, no AIP gets lost and all are kept in one place. Please > keep in mind that this is also the problem we want to solve in Beam and try > to keep track of all the documents we have so far*. It's certainly good to > solve that problem too, if possible. > > Also the AIP structure is something that I find nice - There's place for all > additional resources, JIRAs, discussion in comments and state of the > proposal. Even if we don't choose to use Confluence, we definitely could use > a similar template with all that information for our google docs proposals or > any other tool we stick to. > > Thanks! > > *thank you, Ismael and Alexey, for all the reminders under the proposals to > add them to Confluence list! :) > > wt., 10 gru 2019 o 13:29 jincheng sun <sunjincheng...@gmail.com> napisał(a): >> >> 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 <david.mora...@gmail.com> 于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ý <je...@seznam.cz> 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 >>>>
