Hi, First of all the intention of this email is to try to clarify and later better define the current RFC process and project decision processes. The ultimate goal is to have a single document that would define project bylaws and except other things be a guide for new contributors to quickly get an idea how the project decisions are done.
Currently the RFC voting in defined in [1]. This defines all necessary details about a discussion, proposing changes and voting. However it doesn't say anything about the actual proposals so it can be more or less anything impacting PHP. Also it doesn't say anything about implications of the accepting of the idea (e.g. if it needs be merged) or when it should be used. There is another accepted RFC about release process [2] that defines better for what RFC should be used. Specifically it states that it should be used for the features in the following sentence: > New features or additions to the core should go through the RFC process. It is important to note that the RFC specifically states "SHOULD" and not "MUST" which is something that has been probably applied to many smaller features that didn't go through RFC over the years. It is not exactly clear if this is actually allowed as there is a conflicting note regarding release cycle that kind of says that the feature can get to the next release as long as it gets accepted: > The shorter release cycle also ensures that a given feature can get into the next release, as long as the RFC has been accepted. This could be taken that only RFC accepted feature can go to the next release which kind of conflict with the "SHOULD" above. As you can see it's pretty vague and not exactly something that has been really accepted in practice. The fact is that there is also no definition of the feature so if we took it to the extreme, it could mean any technical change would also need an RFC. I think we all agree that would be really inconvenient so that's something that we should probably better clarify. We then have rules for RMs but they are mainly based around releases. I think it would be good to define that part as well but will leave it aside for now as it is much clearer and less impacting the core development. The only important thing to note is that RM decides about bugs going to the release. It seems that in the current definition, the RFC is just for blocking rejected features to get to the next release rather than requiring accepted features to be in the next release. It means if the RFC is accepted, it can get to the next release but it does not mean that it must get to the next release. Obviously if RFC is rejected, it means that it cannot get to the next release. The implication of that is that to fully accept the feature, it requires someone to merge it and no one to revert it... It means it requires some sort of consensus between core developers or at least no objections from some core developers. This is largely undefined as almost always the core developers would follow the decision in RFC but technically there is nothing in our process that would require them to do so. In terms of conflicts between developers, the RFC does not even have much meaning because of the above. It could be used just as some sort of poll and honour the decision as such but it has no deciding factor in it. This is at least how I understand the linked RFCs so please comment if you think that the analysis is incorrect or I missed anything. I think it would be good to define this somewhere so we can potentially make tweaks into it in the future. The idea is to maybe create a single document in the wiki collecting both linked RFCs with extended clarifications and maybe mirror it in git so the future proposal are easier to do. Thoughts? [1] https://wiki.php.net/rfc/voting [2] https://wiki.php.net/rfc/releaseprocess Cheers Jakub
