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