An RFC process to improve Open Source for Energy Access materials

Community Feedback
1

Context
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

People
The idea is to have two main actors:

  1. Maintainer
    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.

image
image1628Ă—613 73.6 KB

  1. 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.

image
image1604Ă—623 84.4 KB

Non-Technical matters
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.

1 Like
3

Hi Fabio,

We at Angaza have no objection to this proposal – it looks good! We may want to agree up front on a definition for what makes a pull request “too substantial” for acceptance by the Maintainer.

4

Hi @ChadNorvell
great to hear, thanks for the confirmation.
I agree that substantial change is not a very clear indication, and I am generally ok with that, trusting that Angaza, as maintainer, would be best to wing it at the beginning, then we can start codifying it a bit more as we gain experience.
As a general rule, I think that eg adding support for a new device/resource would be substantial, while adding an optional extra property to an existing one would be considered minor. A change that break backward compatibility is substantial.

The ones above are quick examples off the top of my head, but again, I think experience will tell. Also, I think the RFC team should be composed of people that can and will anyways monitor the pull requests (even if they have no direct responsibilities) and eg bring up if they see a pull request that should be seen as substantial, so we can all learn and improve.

Finally, please note that the idea of Angaza being the core maintainer comes from the assumption you guys

  1. want to be the maintainer
  2. see it as the most effective way to proceed

If either of the above are not true, we should find another Maintainer (we can take it, too).

Ciao
fabio

5

This process looks good to us at Simusolar also