Thanks for the insight Jun. It's great to hear that a process that's erring on the side of flexibility, freedom, and under-prescription holds up well in practice!
Have you folks run into any trouble w/lack of alignment (false negatives or positives) on what qualifies as major? > > - Any major new feature, subsystem, or piece of functionality > > On Thu, Jun 11, 2020 at 2:42 PM Jun Rao <jun...@gmail.com> wrote: > Hi, everyone, > > Just want to briefly share our experience in Apache Kafka. This may or may > not apply to the Cassandra community. > > We started the KIP ( > > https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals > ) > process in 2015. The following is the summary of the process. > > 1. It's designed for major new features or changes to public interfaces. > 2. Anyone can start a KIP as long as that person has the intention to carry > it through. > 3. The KIP first goes through a discussion phase and then a voting phase. > The vote requires +1 from at least 3 committers to pass. > > Overall, I think our experience with KIP is positive. It (a) made our > compatibility story much better since more people are paying attention to > public interface changes; (2) allowed major features to be discussed more > thoroughly and often made the original proposal better; (3) non-relevant > KIPs (e.g. covered by existing features or other KIPs) were mostly vetted > out in the early discussion phase. > > We made some minor adjustments along the way. For example, if minor changes > are later discovered during the implementation of an accepted KIP, those > changes can just be added to the voting thread. If there are no objections, > those changes are accepted without the need of a new vote. > > Sometimes, it does feel that KIP adds a bit overhead. For example, changing > a simple configuration requires the same multi-day process. However, that's > probably minor given the overall benefits. > > Thanks, > > Jun >
