Skip to content

Latest commit

 

History

History
82 lines (62 loc) · 4.98 KB

RFC_PROCESS.md

File metadata and controls

82 lines (62 loc) · 4.98 KB

Block Foundation's Request For Comments (RFC) Process Guide

The Block Foundation's RFC process is intended to provide a path for new proposals to enter the projects, so that all stakeholders can be confident about the direction the project is evolving in.

1. Proposal Phase

Anyone can author an RFC. To start the process, create a new file in the RFCs repository using the RFC template. Name the file with a descriptive name, using dashes to separate words, and append a .md file extension (for Markdown). For instance, my-proposal.md.

2. Discussion Phase

Once your RFC is submitted, it enters the Discussion phase. This is an opportunity for community members, other contributors, and stakeholders to provide feedback, ask clarifying questions, and discuss the potential impact of the proposed changes.

Comments and discussions will take place directly in the RFC pull request.

3. Modification Phase

Based on the feedback and comments received during the Discussion phase, you may need to make modifications to your RFC. These changes can be made by pushing commits to the RFC file in your branch.

4. Decision Phase

The decision phase begins once discussion has settled and the changes have been made. The core team will review the proposal and discussions and make a decision on the RFC, which could be one of the following:

  • Approval and merging of the RFC pull request
  • Request for further changes and discussion
  • Closing and rejection of the RFC

5. Implementation Phase

Once an RFC has been accepted, the implementation phase begins. Anyone is welcome to implement an accepted RFC, not just the person who proposed it. Implementation details should be tracked in a separate location (such as an issue or project management tool).

Remember, the RFC process is a tool to foster collaboration, clear communication, and a record of decision-making. As the community evolves, so will this process. If you have suggestions for improving the process, please open an RFC for your proposal.

We look forward to seeing your ideas and working together to continuously improve the Block Foundation's projects.


RFC Process Guide for the Block Foundation Welcome to the Block Foundation's RFC (Request for Comments) process guide. This document is intended to provide a clear and organized structure for introducing, discussing, and implementing new ideas and changes to our various projects and initiatives.

Table of Contents Introduction Process Stages Guidelines for Submission Decision Process Implementation Revision and Amendments

  1. Introduction RFCs are proposals that describe potential changes or improvements to our projects. They enable contributors to articulate their ideas, facilitating an open and collaborative decision-making process. This ensures that our projects evolve in a transparent and community-driven manner.

  2. Process Stages 2.1 Pre-RFC (Discussion) Begin by raising the idea on our community channels, such as Discord or Forum, to gather preliminary feedback. 2.2 Draft RFC Create a draft RFC using the provided template. Submit it as a pull request to the RFC repository. At this stage, it's marked as "draft." 2.3 Discussion Once the draft RFC is submitted, the community and core team members will provide feedback, ask questions, or suggest changes. The original author(s) should address concerns and can make revisions to the proposal. 2.4 Finalizing After a period of discussion and revision, the RFC will be marked as "finalized," ready for a formal review. 2.5 Decision The core team will review the finalized RFC, considering all discussions and feedback. The RFC can be "Accepted," "Rejected," or kept in a "Deferred" state for future consideration. 2.6 Implementation If the RFC is accepted, it moves into the implementation phase, and respective changes are made in the project repository.

  3. Guidelines for Submission Ensure that the RFC is clear, concise, and free of jargon. Detail the motivation behind the proposal, the problem it addresses, and the proposed solution. Highlight any potential drawbacks, trade-offs, or alternative solutions. Provide a clear roadmap for implementation.

  4. Decision Process Every RFC will remain in the discussion phase for at least 30 days to ensure adequate time for feedback. Core team decisions are based on technical merit, community feedback, and alignment with the Block Foundation's goals. A rejected RFC can be re-submitted after significant changes or if circumstances evolve.

  5. Implementation Accepted RFCs will be assigned an owner (either the original author or a community member) responsible for its implementation. Implementation progress should be regularly updated in the RFC document.

  6. Revision and Amendments If substantial changes are required post-acceptance, a new RFC should be created for clarity. Minor changes can be proposed directly to the accepted RFC, but must be approved by the core team. Thank you for participating in the Block Foundation's evolution. We value every contribution and aim for an inclusive, transparent, and innovative community.