Instead of reinventing the wheel let’s see if it is possible to start with the work the Rust community has done. I’d like to propose the Rust RFC model for the Grin community with some minor changes to explore its viability.
Please review the documents and if possible make an argument for why the Rust process would not work well for the Grin community without major adjustments (or if the BIP/PEP process would work better with only minor adjustments).
If no one has major objections to the Rust RFC process, we can use the documents below as a starting point.
Example RFC Process Document
Objectives for this document:
- Introduce the RFC process for Grin
- Describe when to follow the RFC process
- Describe the RFC process
- Describe RFC life-cycle
- Describe process for reviewing, implementing and postponing RFCs
- Describe general philosophy and intention motivating the state of the RFC process
TODO:
- Community review, feedback and iteration
Further considerations:
- Are there good arguments for not using the Rust RFC model? Do they also apply to BIP/PEP?
Example RFC Template
Objectives for this document:
- Provide a template to guide the structure of future RFCs
- Offer a structure generic enough to apply to all substantial changes to Grin
- Ensure the structure guides authors to providing enough specifics for the teams to fully understand and implement features suggested in RFCs
- Ensure the RFC structure will allow Grin community members to clearly understand the contents proposed and their impact
- Encourage engagement, deeper thought and further discussion about unforeseen impacts of the RFC in all aspects of the Grin ecosystem
TODO:
- Community review, feedback and iteration
Example RFC-0000: RFC Process
Objectives for this document:
- Formalize the RFC process in the RFC template structure
- Clarify and make explicit the details in the RFC process document
TODO:
- Community review, feedback and iteration
RFC-0001: Grin Governance
TBD
Generic objectives for this document (full details found here Proposal: Grin Governance Iteration):
- Expand and make more explicit Grin’s governance structure
- Improve transparency around Grin’s governance structure
- Encourage more participation
- Create subteams that focus on specific domains to assist core team
- Describe processes for core team and subteams including formation, decision making, roles and responsibilities
- Formalize these details in the RFC template structure
Unanswered Questions
- Should RFC issues be opened in their respective repos (wallet RFC in wallet repo etc.) or should they all be opened in grin-pm repo?
Important Questions
Currently in Rust’s RFC process, in the “Reviewing RFCs” section, it gives final decision making power to merge or close an RFC pull request to subteams.
- Should the core team get veto power over subteam decisions?
- Should subteams have an ability to collectively veto core team decisions?
- What language can we use to describe a process for agreement if most cases for dispute are best handled in a case by case basis?
The answers to these questions will have larger implications when we begin to explore the construction of the actual governance RFC.