This is an old revision of the document!
PHP RFC: Abolish Narrow Margins
- Version: 0.4
- Date: 2016-11-17
- Author: krakjoe
- Status: Under Discussion
- First Published at: http://wiki.php.net/rfc/abolish-narrow-margins
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.
Anything merged into php-src is by definition a core part of PHP, regardless of the folder it goes into, or whether it has direct implications for our users. This is not a debatable fact: If it is distributed with PHP, it is core software.
RFC's come in the following two categories:
- Proposals to amend or create policy documents
- Proposals to merge code into php-src
This RFC proposes that all RFC's need to meet the same high standard.: Any vote that would result in merges into the source repository, or amend or create policy documentation must require a super majority of 2/3.
This change means that the main vote in any RFC must have a super majority.
Subsidiary votes come in the following two categories:
- Vote to resolve implementation details - ie. Choose between version X and version Y of an implementation for a main vote.
- Vote that could have been run as a separate RFC ie. Their passing would result in merges into the source repository or changes to policy documentation that would otherwise not take place, regardless of the outcome of the main vote.
A subsidiary vote of type 1 may require a slim majority (as per the current definition).
A subsidiary vote of type 2 must require a super majority (as per the current definition).
These new rules are unambiguous, and much more suited to a project the size and scope of PHP.
These rules shall apply to any RFC whose vote ends after this RFC is accepted, should this RFC be accepted.
Proposed Voting Choices
A straight yes/no vote, super majority required to pass.
If this RFC passes the vote, the original voting RFC will be amended (under the heading Required Majority) to reflect current requirements, and have the version changed.
- 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 less 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.