Contributor Repository, Execution Plan

[StevenLuMT]

I. Project background

[improve][pip] PIP-367: Propose a Contributor Repository for Pulsar
When fixing the Client defect mentioned in PIP-359 for Pulsar, Assaf proposed that Pulsar's Client was too bloated and should not be added casually. This led to the idea of a contributor repository.
After discussing with Enrico and Dave, we gradually refined the initial idea and created a repository example in a private repository.
https://github.com/StevenLuMT/pulsar-java-contrib

II. Project motivation

1. Provide default implementation of external interfaces to reduce user development costs
   In order to solve the problem of bloated main repository functions, Pulsar abstracts many functions and provides interfaces for users to implement by themselves. Some of them provide default implementations, while others do not. We will also implement these interfaces and use them in the production environment to make them more powerful.
2. Collect plugin implementations for each interface and separate plugins that are not suitable for maintenance in the Pulsar main repository.
   The scale of these plugins is generally not large, not like the oxia implemented by the company, and their value is limited. They should not be merged into the main Pulsar repository. Contributor repositories can be collected, and valuable plugins that are widely used and improved by users can eventually be incubated and successfully merged into the main Pulsar repository, thereby enriching the Pulsar ecosystem.
3. Collect various experimental functional features
   Some functional communities may have this demand, but some people feel that adding this feature is destructive, and even adding switches is unacceptable. At this time, these features can be moved to the contributor repository after discussion for incubation and development.
4. Collect best practices from users
   Pulsar is a relatively complex project, and there are explanations of various functions on the official website. However, there is no best practice document based on various scenarios.
   If there is a place that can provide scenario-based best practice documentation, it can lower the threshold for users to use Pulsar and help them better use Pulsar.
   [1] Lari also mentioned in PIP-371 that separate repository contribution plugins should be created

III. Project Objectives

Goal 1: Provide a new plugin implementation for each existing open interface
Goal 2: Collect customized requirements from at least three companies to prepare for further development
Goal 3: Operate in the production environment and generate profits
Goal 4: Publish at least three best practice documents