# Hyperswitch RFC Process

Hyperswitch welcomes contributions from anyone in the open-source community. Although some contributions can be easily reviewed and implemented through regular GitHub pull requests, larger changes that require design decisions will require more discussion and collaboration within the community.

To facilitate this process, Hyperswitch has adopted the RFC (Request for Comments) process from other successful open-source projects like Rust and React. The RFC process is designed to encourage community-driven change and ensure that everyone has a voice in the decision-making process, including both core and non-core contributors.

Here are the steps involved:
1. Prepare an RFC Proposal
2. Submit Proposal
3. Complete Initial Review
4. Initiate RFC Discussion
5. Finalize Proposal
6. Complete Implementation
7. Close RFC

**Prepare an RFC Proposal:** Anyone interested in proposing a change to Hyperswitch should first create an RFC(in the format given below) that outlines the proposed change. This document should describe the problem the proposal is trying to solve, the proposed solution, and any relevant technical details. The document should also include any potential drawbacks or alternative solutions that were considered.

**Submit Proposal:** Once the RFC document is complete, the proposer should submit it to the Hyperswitch community for review. The proposal can be submitted either as a pull request to the RFC Documents folder or as a GitHub Issue.

**Complete Initial Review:** After the proposal is submitted, the Hyperswitch core team would review it and provide feedback. Feedback can include suggestions for improvements, questions about the proposal, or concerns about its potential impact.

**Initiate RFC Discussion:** If the initial review results in interest from the community, a discussion should be opened to debate the proposal. The discussion can take place on GitHub or on Hyperswitch’s Slack & Discord servers. The discussion timeframe would be one week unless specified otherwise by the proposer or the core team.

**Finalize Proposal:** During the discussion phase, the proposer should work with the community to refine the proposal based on feedback and input. Once the proposal is deemed mature enough, a final version should be submitted for community review and acceptance. If the proposal is accepted, the proposed changes can be implemented. If the proposal is rejected, the proposer can either abandon the proposal or rework it based on community feedback and resubmit it for another round of review.

**Complete Implementation:** Once the proposal is accepted, the proposer or a designated contributor can implement the changes to the repository. The implementation should follow the design outlined in the RFC document and adhere to any relevant coding standards and guidelines.

**Close RFC:** After the proposal is implemented, the RFC process would be closed by marking the proposal as completed. The RFC document would be kept for future reference, and any feedback received during the process can be used to inform future RFCs.

This RFC process for Hyperswitch is intended to encourage collaboration and communication within the community and ensure that proposed changes to the platform are thoroughly evaluated before implementation. Please note that ​​a lack of response from others is assumed to be positive indifference.

## Templates:

### Issuing an RFC
```text
**Title**

**Objective**
A clear and concise title for the RFC

**Proposal**
A detailed description of the proposed changes, discussion time frame, technical details and potential drawbacks or alternative solutions that were considered

**Open Questions**
Any questions or concerns that are still open for discussion and debate within the community

**Additional Context / Previous Improvements**
Any relevant external resources or references like slack / discord threads that support the proposal
```

### Resolving an RFC
```text
**Title**
The title of the resolved RFC

**Status**
The final status of the RFC (Accepted / Rejected)

**Resolution**
A description of the final resolution of the RFC, including any modifications or adjustments made during the discussion and review process

**Implementation**
A description of how the resolution will be implemented, including any relevant future scope for the solution

**Acknowledgements**
Any final thoughts or acknowledgements for the community and contributors who participated in the RFC process
```