This document describes the procedure to propose an idea for adoption by the PHP community and decide if the community accepts or rejects the idea.
Proposal is formally initiated by creating an RFC on PHP wiki and announcing it on the list. If the proposal is a repeated discussion of an existing RFC, with or without modification, it still should be announced on the list for discussion.
The announcement will be done in a way that's easy to flag & follow, e.g. - by [RFC] in the subject line followed by the title of the RFC.
The proposal should be initiated by one of its authors. If the proposal is a repeated one, re-proposed by somebody else, the proposer should discuss it with the original author, if possible, and add himself to the RFC author list before proposing it.
If the proposer is not a member of php.net and thus can not create RFCs on the wiki, they should recruit one of the members for help or request membership.
There'd be a minimum of 2 weeks between when an RFC that touches the language is brought up on this list and when it's voted on is required. Other RFCs might use a smaller timeframe, but it should be at least a week. The effective date will not be when the RFC was published on the PHP wiki - but when it was announced on internals@, by the author, with the intention of voting on it. This period can be extended when circumstances warrant it - such as major conferences, key people being busy, force major events, or when discussion merits it - but should never be less than minimal time.
This does not preclude discussion on the merits on any idea or proposal on the list without formally submitting it as a proposal, but the discussion time is measured only since the formal discussion announcement as described above.
The author decides when it's time to move ahead and call a vote on the RFC. If the author feels that there's still healthy discussion going on, they can decide not to move ahead to request a vote after the minimal period, but extend it as needed. On the other hand, if they feel that the discussion is being derailed - they can always move ahead to a vote as long as the minimum discussion time elapsed.
The vote is announced on the mailing list in a separate thread by sending an email with the subject [VOTE]. It should reference the RFCs being voted on and if there are different options discussed, explain these options. It should also contain the URL of the page where the vote is taking place.
The voting has minimal period of 1 week, which can be extended when circumstances warrant it.
Given that changes to languages (as opposed to changes to apps or even frameworks) are for the most part irreversible - the purpose of the vote is to ensure that there's strong support for the proposed feature. It needs to be clear that there are a lot more people actively supporting the proposal, vs. people actively opposing it. We also need to ensure, as much as possible, that the decision isn't based on some arbitrary circumstances (such as a temporary marginal majority for a certain school of thought). For these reasons, a feature affecting the language itself (new syntax for example) will be considered as 'accepted' if it wins a 2/3 of the votes. Other RFCs require 50% + 1 votes to get 'accepted'.
In order to save valuable time, it will not be allowed to bring up a rejected proposal up for another vote, unless one of the following happens:
There's no way around this 'small' issue. Changes made to the PHP language will affect millions of people, and theoretically, each and every one of them should have a say in what we do. For obvious reasons, though, this isn't a practical approach.
The proposal here is for two audiences to participate in the voting process: