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

Reply via email to