As part of the conversation around the governance for the Nexus Channel Resource Models, we are thinking what is going to be the best approach to ensure an inclusive, yet pragmatic and quick, governance to improve the Resource Model for Nexus Channel.
We started from a best-practice assessment, and quickly landed on replicating the Request For Comments (RFC) approach already established in a open source projects.
A process example we can take inspiration from is the React one, probably except the Contributor License Agreement (CLA), which seems to be driven by the Facebook legal team. The RFC process can be seen here: https://github.com/reactjs/rfcs
The idea is to have two main actors:
In the case of the Nexus Channel Resource Model, we think it would make sense for Angaza to keep this role, as they are the closest to the code and can quickly judge whether a pull request can be incorporated with little risk or impact.
If the proposed modification is too substantial, the Maintainer would reject the pull request, asking instead and RFC be proposed, following the template provided (something like this). The RFC will then be submitted, again via a pull request, to be then accepted by the RFC team.
- RFC Team
This is a team that will review the RFC requests. The Maintainer is automatically part of this team. Additional members are added based on requests and invites, on a case by case basis. EnAccess will keep an active role in raising awareness and bringing in new members to the RFC Team, although other invites will always be welcome and accepted. In all cases the RFC Team members should be technically qualified to assess the impact of an RFC on the code base.
The RFC Team comments on the RFC directly on the Pull Request conversation page on GitHub, see an example of such discussion here.
10 days after the pull request is issued, the 3 final comment days are started, leading to an approval or rejection within 14 days. The approval is achieved by simple majority within the RFC Team, with the Maintainer vote counting double.
Non-technical matters are not handled via the RFC process, but will instead be discussed on this OSEA Community Platform. This will also be the place to discuss non-tech implications of RFC requests, should there be any. EnAccess will be coordinating these discussions and ensuring that they are brought up here whenever needed. This will allow the Maintainer to limit their involvement to technical/code matters, if they so wish.