Dear Apache RocketMQ Community
When we want the Apache RocketMQ project we propose an ISSUE with feature request on Github. It's a nice way for request but not very formal and easy to trace and manage. So I suggest that we should introduce the RIP(RocketMQ Improvement Proposal) mechanism to replace current Feature Request Process. So here are some key issues we need to discuss and make consensus. What is RIP? Why we need RIP? the Process and Status of a RIP How do we cooperate in RIP way to request or offer a feature? Should we provide a RIP template? What is the RIP template? The answers to above questions are included in my draft, so let's make these document better. The illustration and template of RIP are now available on Google Doc, links are: RocketMQ Improvement Proposals RIP Template Comments, suggestions and editing are welcome! Since Google Doc service is not accessible in China mainland, the content of these two document would be quoted below: RocketMQ Improvement Proposals RocketMQ Improvement Proposals What is a RIP? This page describes a proposed RocketMQ Improvement Proposal(RIP) for proposing a major change to Apache RocketMQ, which is similar to a product requirement document commonly used in product management. RIPs should be used for significant user-facing or cross-cutting changes, not small incremental improvements. When in doubt, if a committer thinks a change needs an RIP, it does. RIP Process & Status Process Propose a RIP DISCUSS VOTE Implement Review & PR Status Write a proposal => Proposed Start a discussion on mailing list with all the community members => Discuss Start a Voting process in the community after discussing => Vote Reach an agreement in the community and start implementing => Implementing The Pull Request about this proposal is merged => Implemented The community decide to discard this proposal after voting => Discard RIP Way Role Any community member can take part in discussing about whether a RIP meets their needs, and propose a RIP. Contributors can help by discussing and suggesting the technical details about a RIP, including but not limited to design, implementation, testing and document. RIP Authors are community members proposing a RIP and committed to pushing the change through the entire process. RIP Shepherd is a PMC member who is committed to shepherding the proposed change throughout the entire process. The shepherd is ultimately responsible for the success or failure of the RIP. Responsibilities of the shepherd include, but not limited to: Be the advocate for the proposed change Help push forward on design and achieve consensus among key stakeholders Get feedback from users and iterate on the design, implementation, testing and document Verify the changes and uphold the quality of the changes Cooperation A RIP must apply to the RIP template, see this example for more details. All discussion should take place on public mailing list Mails and documents should be archived once process of RIP completed RIP Template: RIP Template Status Current State: {Proposed, Discussing, Voting, Implementing, Implemented, Discard} Authors: [author](github_link),[author](github_link),... Shepherd: [author](github_link) Mailing List discussion: <apache mailing list archive> Pull Request: #PR_NUMBER Released: <relased_version> Background & Motivation What do we need to do Will we add a new module? Will we add new APIs? Will we add new feature? Why should we do that Are there any problems of our current project? What can we benefit proposed changes? Goals What problem is this proposal designed to solve? To what degree should we solve the problem? Non-Goals What problem is this proposal NOT designed to solve? Are there any limits of this proposal? Changes Interface Method signature changes method name parameter list return value Method behavior changes CLI command changes Log format or content changes Compatibility, Deprecation, and Migration Plan Are backward and forward compatibility taken into consideration? Are there deprecated APIs? How do we do migration? Proposed Implementation Outline We will implement the proposed changes by n phases. Phase 1 do xxx do yyy do zzz Phase 2 do xxx do yyy do zzz ... Phase n do xxx do yyy do zzz Rejected Alternatives How does alternatives solve the issue you proposed? Pros and Cons of alternatives Why should we reject above alternatives ---- Best Regards Zongyang