search

OpenCyphal / specification

The Cyphal specification documents are maintained here.
https://opencyphal.org/specification
Creative Commons Attribution 4.0 International
41 stars 13 forks source link

proposal for RFC process #116

Closed thirtytwobits closed 2 years ago

thirtytwobits commented 2 years ago

I approve the direction in which this is going but at the same time it feels like imposing too much structure upon our lax workflow. Is there an option to reduce the text by about three-fold to let it state only the following general ideas: RFCs are proposed on the forum, after some initial discussion they are promoted to pull requests, and if the maintainers are happy, the pull requests are accepted; the maintainers undertake to act in the best interest of the project? I don't think we have a sufficient track record of accepting external RFCs to justify the existence of strict regulation here.

I'm open to de-lawyer this text by about half but I also want to communicate that maintainers have a responsibility to not just ram things through. There has to be some amount of time an RFC is left open for comment. How about something more like, RFCs are proposed on the forum, after some initial discussion and at least 10 days, they are promoted to pull requests, and if the maintainers are happy, the pull requests are accepted; the maintainers undertake to act in the best interest of the project?

pavel-kirienko commented 2 years ago

That sounds agreeable.

thirtytwobits commented 2 years ago

How do we go from a specification pull-request to a functional change in the OpenCyphal repositories?

This is not detailed as we are trying to keep this process informal, however, my expectation is the blast-radius of a given change would be a key discussion on the forum review of the RFC. This would include concerns by the community about their own implementations as well as maintainers considering how the proposed change would be rolled out in the reference implementations.