Overview
This is an informal guide on how to participate in the governance process for hyUSD by starting a Request For Comments (RFC).
This post covers what an RFC is, how to construct one, and what is expected from the author during and after the RFC process.
What is a Request For Comments?
A Request For Comments is an initial stage in the governance process for hyUSD. It serves as a means to collect opinions and input from the community regarding a proposed change to hyUSD. This feedback can then be utilized to enhance the proposal, following which an on-chain Improvement Proposal (IP) can be created through the Register dApp.
Constructing a Request For Comments
When submitting an RFC on the governance forum, the post should cover all the information of the potentially final IP. This will allow the community to provide feedback & improvements. It is also recommended to add a community poll to your RFC to reach a rough consensus to maximize the chances of positive outcome of the IP.
Here is a template you can use to create RFCs:
| Title | Description |
|---|---|
| Summary | Describe the outcome the proposed change intends to achieve. This should be non-technical and accessible to a casual community member. |
| Abstract | A short (~200 word) description of the proposed change, the abstract should clearly describe the proposed change. This is what will be done if the proposed change is implemented, not why it should be done or how it will be done. |
| Problem statement | This is the why of the RFC. It should clearly explain why the current state of hyUSD is inadequate. It is critical that you explain why the change is needed - why the proposed change is superior to the existing situation. This is not the place to describe how the RFC will address the issue! |
| Rationale | This is where you explain the reasoning behind how you propose to solve the problem. Why did you propose to implement the change in this way, what were the considerations and trade-offs. The rationale fleshes out what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion. |
| Risks | Describe what the risks behind your proposed change are. What could go wrong after this change has been implemented? What would need to happen for that situation to occur? What are the chances of that situation occurring? |
| Community poll | This is a reminder to add a community poll to your RFC. |
How to add a poll to an RFC
1 - Click the gear icon in the toolbar and select “Build Poll”:
2 - Select “Single Choice” and create a “Yes” and “No” option. Press “Insert Poll” to create your poll:
