PHP RFC: Abolish Narrow Margins
- Version: 0.4
- Date: 2016-11-17
- Author: krakjoe
- Status: Accepted
- First Published at: http://wiki.php.net/rfc/abolish-narrow-margins
Introduction
When the RFC process was enshrined in internal law, we were very aware that setting the bar too high for new features may reduce the number of contributors we had. We decided that it was acceptable for a “non-language feature” to be merged with only a slim majority of 50%+1.
The nomenclature “language feature” is misleading and confusing, for new contributors and old alike - some people think it is synonymous with “syntax”, others think it anything that is merged into /Zend, others think it anything that faces the end user. Various definitions have co-existed in the minds of contributors because we have never taken the effort to define exactly what “language feature” includes or excludes.
Proposal
RFC's come in the following two categories:
- Proposals to make changes to PHP
- Proposals to amend or create policy documents
This RFC proposes that all RFC's need to meet the same high standard: The main acceptance vote of any RFC must require a super majority of 2/3.
If this RFC is accepted, the original voting RFC will be amended as per the Normative Text section of this RFC.
These rules shall apply to any RFC whose vote ends after this RFC is accepted, should this RFC be accepted.
Normative Text
Under the “Required Majority” heading, the following text is REMOVED:
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'.
And instead the following text is ADDED:
The primary vote of an RFC, determining overall acceptance of the proposal, may only have two voting options and requires a 2/3 majority. This means that the number of Yes votes must be greater than or equal to the number of No votes multiplied by two.
Additionally, an RFC may have secondary votes, which are used to decide implementation details. Such votes may have more than two voting options and may be decided by simple plurality. This means that the voting option with the most votes wins. If there are multiple options with the most number of votes, it is left at the discretion of the RFC author to choose one of them.
For procedural reasons, multiple RFCs may be combined into one, in which case there may be multiple primary votes. Combining multiple RFCs into one does not allow turning a primary vote into a secondary vote.
No changes to other sections of the voting RFC are made.
Proposed Voting Choices
A straight yes/no vote, 2/3 super majority required to pass.
Voting started on Friday 8th February, finishes Friday 22nd February.
Discussion Topics
- Suggestion that we should raise standard even higher (75%): rejected on the grounds that the bar is high enough at 2/3, we don't want fewer contributions, we want clearer outcomes.
- Suggestion that we should introduce quorum: this is not the topic of this RFC.
- Suggestion that we should change who can vote: this is not the topic of this RFC.
- Suggestion that we should always require a reason to accompany a negative vote: this is not the topic of this RFC.