[DISCUSS] Introduce RocketMQ Improvement Proposal

[Xiao Zongyang <xi...@qq.com>]

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

Re: [DISCUSS] Introduce RocketMQ Improvement Proposal

[Xiao Zongyang <xi...@qq.com>]

Sorry for adding wrong receivers! I'm sorry for disturbing you guys.


Zongyang

Re: [DISCUSS] Introduce RocketMQ Improvement Proposal

[Xiao Zongyang <xi...@qq.com>]

Sorry for adding wrong receivers! I'm sorry for disturbing you guys.


Zongyang