About the Ren Improvement Proposals | RFC category

Requests For Comment | RFC
1

RFCs

This is where you can post a Request For Comment (RFC) proposal and find all previous ones.

TL;DR an RFC is opened to discuss a potential change to RenVM. The goal for an RFC is to use community discussion to evolve into a RIP.

Requests For Comment (RFCs) 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.

An RFC is the first step when proposing changes to RenVM. It can be a full, or partial, proposal that is expected to evolve over time as a result of discussion. Although it is expected that an RFC will change over its life, it is still required to be clear and concise with respect to the change that it is proposing.

RFCs can be accepted or rejected. An accepted RFC is one that has received enough support from the community that an appropriate RIP can be opened. This usually means the RFC has been discussed in enough depth that all ambiguities and concerns have been addressed. When an RFC is accepted, this does not mean that the respective changes will be implemented. It means that an appropriate RIP can be opened.

Table of Contents

  • When you need to follow this process
  • Before creating an RFC
  • Reviewing RFCs
  • Next Steps

When you need to follow this process

You need to follow this process if you intend to make “substantial” changes to RenVM, its supporting infrastructure, or the RFC/RIP process itself. What constitutes a “substantial” change is evolving based on community norms and varies depending on what part of the ecosystem you are proposing to change.

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.

Before creating an RFC

A hastily-proposed RFC can hurt its chances of acceptance. Low-quality proposals, proposals for previously-rejected features, or those that don’t fit into the near-term roadmap, may be quickly rejected, which can be demotivating for the unprepared contributor. Laying some groundwork ahead of the RFC can make the process smoother.

Although there is no single way to prepare for submitting an RFC, it is generally a good idea to pursue feedback from the community beforehand, to ascertain that the RFC may be desirable; having a consistent impact on the project requires concerted effort toward consensus-building.

As a rule of thumb, receiving encouraging feedback from team members, long-standing project developers, and community members is a good indication that the RFC is worth pursuing.

RFCs must follow this template:

  1. Name, scope, and objective.
  2. Categorize the RCF 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 (where applicable).
  5. Provide any low-level details of the proposal (it is expected that these details will grow/evolve as a result of discussion).
  6. What is needed to implement the proposal.

Reviewing RFCs

  1. Once submitted, the RFC should be open for discussion for at least one week (assuming it is well-formed).
  2. While the RFC is open, the team and community should reach out to the author, stakeholders, and each other to discuss relevant issues in greater detail (especially regarding points 5 and 6 from the template).
  3. After one week, the team will determine if consensus has been reached as to whether to RFC is generally favourable or unfavourable, or has any outstanding technical concerns. The team may decide to leave the RFC open for longer if the discussion is still ongoing.
  4. If the RFC is generally considered favourable and has no outstanding technical concerns, the team will signal that an appropriate RIP should be opened by the author (or others).

The team makes final decisions about RFCs. When a decision is made, it will be clearly signalled on the RFC 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

Please refer to RIPs for the next steps.

Acknowledgements

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

3 Likes