I'm sorry, I stole the number 1 from you. Feel free to give suggestions on the form, so we can get a good template for further BIPs
_/ _/ Alex Van Boxel On Sun, Feb 9, 2020 at 6:43 PM Jan Lukavský <je...@seznam.cz> wrote: > Hi Alex, > > this is cool! Thanks for pushing this topic forward! > > Jan > On 2/9/20 6:36 PM, Alex Van Boxel wrote: > > BIP-1 is available here: > https://cwiki.apache.org/confluence/display/BEAM/%5BBIP-1%5D+Beam+Schema+Options > > _/ > _/ Alex Van Boxel > > > On Sat, Feb 1, 2020 at 9:11 PM Kenneth Knowles <k...@apache.org> wrote: > >> Sounds great. If you scrape recent dev@ for proposals that are not yet >> implemented, I think you will find some, and you could ask them to add as a >> BIP if they are still interested. >> >> Kenn >> >> On Sat, Feb 1, 2020 at 1:11 AM Jan Lukavský <je...@seznam.cz> wrote: >> >>> Hi Kenn, >>> >>> yes, I can do that. I think that there should be at least one first BIP, >>> I can try to setup one. But (as opposed to my previous proposal) I'll try >>> to setup a fresh one, not the one of [BEAM-8550], because that one already >>> has a PR and rebasing the PR on master for such a long period (and it is >>> likely, that final polishing of the BIP process will take several more >>> months) starts to be costly. I have in mind two fresh candidates, so I'll >>> pick one of them. I think that only setuping a cwiki would not start the >>> process, we need a real-life example of a BIP included in that. >>> >>> Does that sound ok? >>> >>> Jan >>> On 2/1/20 5:55 AM, Kenneth Knowles wrote: >>> >>> These stages sound like a great starting point to me. Would you be the >>> volunteer to set up a cwiki page for BIPs? >>> >>> Kenn >>> >>> On Mon, Jan 20, 2020 at 3:30 AM Jan Lukavský <je...@seznam.cz> wrote: >>> >>>> I agree that we can take inspiration from other projects. Besides the >>>> organizational part (what should be part of BIP, where to store it, how to >>>> edit it and how to make it available to the whole community) - for which >>>> the cwiki might be the best option - there are still open questions about >>>> the lifecycle of a BIP: >>>> >>>> a) when to create one? >>>> >>>> - I feel this might be optional, there might be some upper bound of >>>> features that are really "too big" or "too controversial", so these should >>>> undergo the BIP process in all cases, otherwise the decision might be part >>>> of the proposal, the question is how to define those >>>> >>>> b) what are lifecycle stages of a BIP? How to do transitions between >>>> these stages? >>>> >>>> - From the top of my head this might be: >>>> >>>> a) proposal -- not yet accepted >>>> >>>> b) accepted -- most probably after vote? >>>> >>>> c) in progress -- having assigned JIRA and being worked on >>>> >>>> d) done -- after merge to master >>>> >>>> e) released -- obvious >>>> >>>> WDYT? >>>> >>>> Jan >>>> On 1/15/20 8:19 PM, Kenneth Knowles wrote: >>>> >>>> Focusing this thread on the BIP process seems wise, without changing >>>> much else in the same thread. I don't think the BIP process has to do with >>>> exactly how design docs are written or archived, but the ability to *at a >>>> glance* understand: >>>> >>>> - what are the high level proposals >>>> - status of the proposals >>>> - who to contact >>>> - how to get to more info (links to design docs, thread, Jiras, etc) >>>> >>>> A page with a table on cwiki is common and seems good for this. How we >>>> manage such a table would be a possible next step. I think they should >>>> focus on large changes that need heavyweight process, so should encourage >>>> lightweight creation. I think adding heavy process to smaller changes would >>>> be bad. >>>> >>>> ---- >>>> >>>> I have looked multiple times at other projects (linked in prior thread >>>> and in this thread too but gathering them here) >>>> >>>> Spark: https://spark.apache.org/improvement-proposals.html >>>> - Jira is not good for "at a glance" reading. The title should have a >>>> short and easy to understand paragraph. >>>> >>>> Kafka: >>>> https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals >>>> - Quite a lot of content; I would prefer 10s of proposals. But it is >>>> readable enough. Table lacks important content like links and summaries. >>>> - Blends the table with a bunch of header material that IMO ets in the >>>> way >>>> >>>> Flink: >>>> https://cwiki.apache.org/confluence/display/FLINK/Flink+Improvement+Proposals >>>> - Looks very similar to Kafka >>>> - Target Release is too specific, and actual status is missing >>>> >>>> Airflow: >>>> https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvements+Proposals >>>> - seems best organized, and the table has more info >>>> - having sections for the different status proposals in different >>>> tables is great >>>> - "InRelease" column is left blank >>>> >>>> It seems there is a lot of redundancy with Jira fields - owner, >>>> release, etc. I think that redundancy is good. If it is too much effort to >>>> redundantly manage to write it in the table then it probably is not >>>> appropriate for heavyweight process. Anything that is one simple task that >>>> fits in a Jira that can be passed around from person to person shouldn't be >>>> a BIP. Probably anything where we can guess the target version isn't big >>>> enough for a BIP. >>>> >>>> Kenn >>>> >>>> On Thu, Jan 9, 2020 at 7:59 AM Jan Lukavský <je...@seznam.cz> wrote: >>>> >>>>> I think that, besides ownership of a feature, a BIP (or whatever >>>>> document or process) should contain the following: >>>>> >>>>> * description of a problem that the improvement addresses - this is >>>>> currently often part of design doc >>>>> >>>>> * description of multiple possible solutions (if multiple exist, >>>>> which is probably mostly the case) >>>>> >>>>> * justifying choice of a particular solution >>>>> >>>>> * result of a vote - the vote should cover both (a) do we don't this >>>>> feature in the first place and (b) do we accept the proposed solution >>>>> >>>>> This would probably be iterative process involving multiple people, >>>>> mailing list communication, etc. Pretty much what we do now, just there >>>>> would be a place to keep track of decisions made throughout the process. I >>>>> pretty much think that voting on complicated solutions is vital, the soft >>>>> consensus approach is good for "simple" features (what that means might be >>>>> subjective), but might fail for features where multiple more or less >>>>> complex solutions exist. After successful PMC vote, the problem simplifies >>>>> to reviewing code, the reviewer doesn't have to think about "do we want >>>>> this feature?". That is given in advance. After we agree on the process >>>>> and >>>>> the form it should have I can volunteer to test it by letting proposal of >>>>> ordered stateful processing pass through it. >>>>> On 1/9/20 9:11 AM, Alex Van Boxel wrote: >>>>> >>>>> Maybe tweaking the current process a bit is enough. I like the Docs >>>>> for having discussions but there no good as a *proper design document*, >>>>> for the following reasons: >>>>> >>>>> I see design documents full of discussions and wonder: >>>>> >>>>> - Who will be the *main owner* and the *co-owners* (meaning people >>>>> that are invested of bringing this forward and can *act* as >>>>> *reviewers*). I think a proposal needs especially this: ownership >>>>> - Lack of visibility of final state? Or is it superseded by >>>>> another proposal. A final state could include the votes... >>>>> - Does the proposal need amendments. An example, while >>>>> implementing the proposal, we see that something in the design was >>>>> lacking >>>>> and needs to be added. >>>>> >>>>> So the Docs are great, but maybe we should a few mandatory blocks and >>>>> a few rules: >>>>> >>>>> - *Resolve all discussions* before switching to final state. >>>>> - If new discussions pop up, maybe an amendment needs to be made >>>>> (or correct). Corrections could be added to a *changelog* in the >>>>> beginning. >>>>> - If a new proposal supersedes on, both should be linked >>>>> - Most importantly: Who can act as *owner* end reviewers for this >>>>> proposal. >>>>> >>>>> >>>>> >>>>> _/ >>>>> _/ Alex Van Boxel >>>>> >>>>> >>>>> On Thu, Jan 9, 2020 at 7:59 AM Kenneth Knowles <k...@apache.org> >>>>> wrote: >>>>> >>>>>> It does seem that the community would find this useful. I agree with >>>>>> Robert that it has downsides and it is not appropriate all the time. >>>>>> >>>>>> We added https://beam.apache.org/roadmap/ a little while ago. I >>>>>> think that the granularity of a BIP is about the same as the granularity >>>>>> of >>>>>> what we would want to show to users on a roadmap on our public site. So >>>>>> we >>>>>> sort of already have this. Perhaps we want to formalize changes to the >>>>>> roadmap and only include voted upon approved BIPs on the roadmap on the >>>>>> web >>>>>> site. The current roadmap should be viewed as a crowd sourced bootstrap, >>>>>> for sure. >>>>>> >>>>>> Imagine a roadmap that a company shares with a customer. The most >>>>>> important thing is to be extremely clear about what is intended to be >>>>>> built, when it is expected, and how they can follow the developments. And >>>>>> for the open source community, it should be clear what they can expect to >>>>>> work on and know that the project / PMC has agreed on the feature and >>>>>> will >>>>>> not push back after some effort has been put into it. >>>>>> >>>>>> Kenn >>>>>> >>>>>> On Tue, Dec 17, 2019 at 11:07 AM Jan Lukavský <je...@seznam.cz> >>>>>> wrote: >>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I feel a "soft consensus" :) that people see some benefits of >>>>>>> introducing (possibly optional) process of proposing new features. >>>>>>> >>>>>>> I think that in order to proceed with this we need to agree on goals >>>>>>> that we want to achieve. Whether the process should or should not be >>>>>>> optional, which form it should have, and answers on all these other >>>>>>> questions could be answered after that. >>>>>>> >>>>>>> So, I'll try to state some issues I see with our current approach, >>>>>>> please feel free to correct any of them, or add any other: >>>>>>> >>>>>>> - due to the "soft consensus" approach, we actually delegate the >>>>>>> final responsibility of "feature acceptance" to reviewer(s) - these >>>>>>> might >>>>>>> or might not be happy with that >>>>>>> >>>>>>> - by splitting this into >>>>>>> first-consensus-then-implementation-then-review approach, we remove the >>>>>>> burden of responsibility of respective feature from reviewers - they can >>>>>>> focus only on the main purpose of the review - that is verifying the >>>>>>> quality of code >>>>>>> >>>>>>> - as mentioned before, this brings better visibility to (core) >>>>>>> features >>>>>>> >>>>>>> - and last but not least makes it possible to prioritize work and >>>>>>> build more complex long-term goals >>>>>>> >>>>>>> I think it is essential to have a consensus on whether or not these >>>>>>> are some points we want to target (that is, we see our current approach >>>>>>> as >>>>>>> sub-optimal in these areas) or not. >>>>>>> >>>>>>> Jan >>>>>>> On 12/17/19 7:08 PM, Pablo Estrada wrote: >>>>>>> >>>>>>> It seems that lots of people see benefit in a more formalized BIP >>>>>>> process. I think that makes sense, though I'd like to give people the >>>>>>> freedom to choose the medium for their design discussions. >>>>>>> >>>>>>> The projects I'm aware of usually do this through wiki-type mediums. >>>>>>> We have cwiki, though lots of people like working with Gdocs' >>>>>>> collaboration >>>>>>> features. Are there other mediums that could be used for this? >>>>>>> >>>>>>> A possible implementation is: We could keep cwiki as the 'index' - >>>>>>> so anyone proposing a new BIP would have to add a new BIP entry in the >>>>>>> cwiki, but they'd be free to link to a Gdoc from there, or to develop >>>>>>> the >>>>>>> proposal in the cwiki entry itself. >>>>>>> >>>>>>> Thoughts? >>>>>>> Best >>>>>>> -P. >>>>>>> >>>>>>> On Tue, Dec 17, 2019 at 9:14 AM Maximilian Michels <m...@apache.org> >>>>>>> wrote: >>>>>>> >>>>>>>> The main benefit of BIPs I see is the visibility they create for >>>>>>>> the >>>>>>>> project users and contributors. >>>>>>>> >>>>>>>> Right now, we have a long unordnered list of design documents. Some >>>>>>>> of >>>>>>>> the documents are not even in that list. With BIPs, we would end up >>>>>>>> with >>>>>>>> an ordered list "BIP-1, BIP-2, .." which reflects important design >>>>>>>> decisions over time. >>>>>>>> >>>>>>>> Simply assigning an id, makes it a lot more formal. In my eyes, the >>>>>>>> id >>>>>>>> assignment would also require that you communicate the changes in a >>>>>>>> way >>>>>>>> that the community can accept the proposal, preferably via lazy >>>>>>>> consensus. All in all, this could help communicate changes in Beam >>>>>>>> better. >>>>>>>> >>>>>>>> JIRA, on the other hand, contains concrete implementation steps and >>>>>>>> all >>>>>>>> kinds of other changes. >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Max >>>>>>>> >>>>>>>> On 16.12.19 21:41, Robert Bradshaw wrote: >>>>>>>> > 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 >>>>>>>> >>>>> >>>>>>>> >>>>>>>
