About the Ren Improvement Proposals | RIP category

Ren Improvement Proposals | RIP
1

RIPs

This is where you can post a Ren Improvement Proposal (RIP) and find all previous ones.

TL;DR a RIP is opened to propose a change to RenVM. The goal for a RIP is to use community discussion to reach consensus about the acceptance/rejection of a change exactly as it has been described in the proposal.

Ren Improvement Proposals (RIPs) are intended to be part of a consistent and controlled path for proposing changes to RenVM, so that all stakeholders can be confident that RenVM is evolving towards a common utility for the whole blockchain ecosystem, and so that all stakeholders have the opportunity to be heard.

A RIP is the second step when proposing changes to RenVM. It must be a complete proposal that is clear, concise, and unambiguous. All parameters must have clearly stated initial values, and clearly state methods for change through governance. RIPs cannot change once they have been proposed.

RIPs can be accepted or rejected . An accepted RIP is one that has been assessed to be complete and favourable by the majority of active community members. In the future, completion, acceptance, and rejection will all be part of an on-chain governance mechanism with no central parties. For now, the Ren core development team maintains the right to assess the completion/acceptance/rejection of RIPs at its discretion.

Table of Contents

  • When you need to follow this process
  • Before creating a RIP
  • Accepting and rejecting RIPs
  • Next Steps

When you need to follow this process

You need to follow this process if you intend to make changes to RenVM, or its supporting infrastructure, regardless of the change. This does not include configurations/settings that are specific to your own nodes.

An RFC does not always need to be opened before a RIP. This depends on whether or not community norms have already been established for the change (e.g. changing the % of minting/burning fees is simple and non-ambiguous enough that a RIP can be opened without an RFC). However, changes that do not have established norms must have an accepted RFC before an associated RIP can be opened. RIPs are expected to link to their supporting RFC when relevant.

Before creating a RIP

A hastily-proposed RIP will be rejected. This includes low-quality proposals, proposals for previously-rejected features, or those that don’t fit into the near-term roadmap. As a rule of thumb, you should begin by opening an RFC. This will allow you to discuss the specifics of your change with the rest of the community. Once the RFC has been sufficiently discussed and accepted, opening the appropriate RIP should be straight-forward. The key difference between RFCs are meant to evolve through discussion, and RIPs are meant to be accepted/rejected through discussion.

RIPs must follow this template:

  1. Name, scope, and objective.
  2. Categorize the RIP into one of these categories: Protocol, Token, Governance, or Other.
  3. Provide a brief high-level overview of the proposal.
  4. Provide a relevant history of the proposal and how similar initiatives have been successful in the past.
  5. Provide all low-level details of the proposal.
  6. What is needed to implement the proposal.

This template is all but identical to the RFC template, with the exception that no parts of the template are optional.

Accepting and rejecting RIPs

  1. Once submitted, the RIP should be open for discussion for at least one week (assuming it is well-formed).
  2. While the RIP is open, the team and community should present arguments to justify its acceptance or rejection.
  3. After one week, the team will determine if consensus has been reached as to whether to RIP has a majority support from the community. The team may decide to leave the RIP open for longer if the discussion is still ongoing.
  4. If the RIP has a majority support from the community, the team will signal that it has been accepted.

The team makes final decisions about RIPs. When a decision is made, it will be clearly signalled on the RIP thread.Regardless of acceptance or rejection, if the reasoning is not clear from the discussion in thread, the team will provide a rationale for the decision. All community members are encouraged to challenge any decisions that they think have been made in error.

Next Steps

After a RIP has been accepted, its implementation will be planned and added to the backlog of the Ren core development team. This will include an indication of priority and estimated delivery date (where possible).

Acknowledgements

The RIP process is a modified version of GitHub - rust-lang/rfcs: RFCs for changes to Rust.

1 Like