And https://cwiki.apache.org/confluence/spacedirectory/view.action maybe a good candidate.
On Mon, Feb 3, 2020 at 7:01 PM Kun Song <songkun...@gmail.com> wrote: > There is one more thing I'm concerned about, should we find a centralized > place to put all PIPs? If not, PIPs will be scattered across the internet. > > On Mon, Feb 3, 2020 at 5:30 PM Sijie Guo <guosi...@gmail.com> wrote: > >> Hi all, >> >> We are using PIP for adopting major changes to Pulsar. It was done in a >> lazy-consensus way. It was very efficient for growing the community and >> driving innovations in the Pulsar community. However, we don't have a >> clear >> workflow for PIP. It is actually causing some confusion and >> inconsistencies. >> >> 1) New contributors don't know where to start with new major >> contributions. >> 2) We don't have a clear definition of what are major changes. >> >> I'd like to start a thread to discuss a few things about PIP and try to >> formalize the PIP workflow. >> >> a) What is considered a "major change" that needs a PIP? >> b) What should be considered to be included in a PIP? >> c) What is the process? >> >> -- >> >> Here is my proposal. >> >> a) Any of the following should be considered a major change: >> >> - Any major new feature, subsystem, or piece of functionality >> - Any change that impacts the public interfaces of the project. >> >> What are the "public interfaces" of the project? All the following are >> public interfaces that people build around: >> >> - Client and Admin API. >> - Wire protocol. >> - Storage (both data and metadata) formats. >> - User-facing scripts/command-line tools, i.e. bin/pulsar, >> bin/pulsar-admin, bin/pulsar-daemon. >> - Docker images >> - Configuration settings >> - Exposed monitoring information (Prometheus metrics, topic stats and >> etc). >> >> For the most part monitoring, command-line tool changes, and configs are >> added with new features so these can be done with one single PIP. And they >> should be well documented. >> >> All these major changes should be shouted out in the release notes. >> >> b) I don't think we need to enforce a format for this PIP. However, we >> should encourage people including the following format. >> >> - Motivation: describe the problem to be solved. >> - Proposed changes: describe the new thing you want to do. >> - New / Changed Public Interfaces: impact on any of the "compatibility >> commitments" described above. The changes should be incorporated into >> documentation and called out in the release note. So everyone thinks about >> them. >> - Migration Plan and Compatibility: If this feature requires additional >> support for a non-downtime upgrade, describe how that will work. >> - Rejected Alternatives: What are the other alternatives you considered >> and >> why are they worse? >> >> c) What is the process? >> >> Anyone can initiate a PIP but you shouldn't do it unless you have the >> intention of getting the work done to implement. >> >> You can write a PIP in a google doc or a gist and send an email to dev >> mailing list to start a conversation with the community. >> >> The PIP is adopted via a lazy-consensus approval process. You can start >> working on the PIP unless you see concerns from other people in the >> community. Try to answer those comments and improve your PIP. >> >
