Hi Simon,
> Well, more than 7 weeks later… Hum, does it mean that the Guix project > is not interested in formalizing some RFC? > > WDYT about the proposal? I just got back from travels and finally caught up with important email. I read the proposal and it looks good to me. Thank you for working on this! This would be the first project I contribute to that has an RFC process, so I don’t know what to look out for. My concerns may thus be completely out of touch with reality, so beware as you read on. It seems to me that the exact process is a little vague, especially with regard to how long the comment period should be, and what expectations there are during this period. There is a chance that the open comment period will lead to derailing discussions of tangents that make it hard for the submitter to answer to real issues (because it would become increasingly difficult to read all messages). I’m thinking of some of the big discussions on the devel list in the past that became too big to follow, and resulted in “consensus by attrition”. Do you know how other projects avoid needlessly dragging on discussions about RFCs? Will *any* disagreement have to be addressed, or will there be an implicit weighing of opinions? As the project grows bigger there can be a problem of having inexperienced contributors (or those with qualifications that are irrelevant to the proposal) block the RFC without malicious intent by essentially requiring to be tutored on areas outside of their expertise. I wouldn’t trust myself to write an RFC without having played with an implementation first. I have doubts whether RFCs that are written without a proof of concept could reasonably be evaluated. Often details and subtle problems are discovered only when playing with a patch, and this may happen only after an RFC has been accepted. Can we take back approval in this RFC process? And lastly a typo: * “subtilities” should probably be “subtleties”. -- Ricardo