Skip to content

Instantly share code, notes, and snippets.

@krakjoe

krakjoe/intro.md Secret

Created September 16, 2019 07:52
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save krakjoe/ffa5c088875990ba0a0ce4fa8fabda83 to your computer and use it in GitHub Desktop.
Save krakjoe/ffa5c088875990ba0a0ce4fa8fabda83 to your computer and use it in GitHub Desktop.
Download ZIP
introduction collab
Raw
intro.md

The development of PHP is community driven by the RFC process described in this document. Anyone may initiate an RFC for any subject. At the end of the RFC process a vote is held among PHP developers to determine if the proposal is to be accepted.

Should a proposal be accepted, the developers of PHP are committed to making the change.

In some circumstances, merging an implementation into the source code of PHP may be delayed because of shortcomings in that implementation. In these cases, resolution of these shortcomings is the responsibility of the proposer.

Should a proposal be accepted without an implementation, it is the responsibility of the proposer to provide one.

@brzuchal
Copy link

My understanding is as follows
First paragraph: as a part of community everyone can propose an RFC and push it on discussion but the PHP developers hold the right to accept or reject the RFC.

Second paragraph: When RFC is accepted PHP developers are commited to provide an implementation (author or other PHP developer who volunteer) and merge patch.

Third paragraph: Merging can be delayed due to bad code or conflicts and it's the responsibility of proposer to solve that issue.

Last paragraph: If the proposal is accepted without implementation proposer responsibility is to provide one and ask for meging it.

@mega6382
Copy link

I quite like the idea of RFC and what it entails, because to me it allows the community as a whole to take control of PHP. And so usually only those RFCs are accepted that benefit the community at large. And PHP doesn't have a BDFL like some other OSS and thus I quite prefer the RFC method and completely disagree with giving any individual power to veto or whatever. Everything should be put to vote, but the conditions surrounding them can be altered(via an RFC, of course) like how much majority is required for what kind of change and who is qualified to vote etc.

@Danack
Copy link

Danack commented Sep 17, 2019

The second sentence is quite dangerous, and should not be used imo. If it was suggested, and then declined, the implication would be that there is a limit on what can be proposed, which doesn't currently exist.

I agree with what you wrote apart from that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment