rfc:abolish-narrow-margins

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
rfc:abolish-narrow-margins [2019/02/06 16:13]
nikic
rfc:abolish-narrow-margins [2019/02/22 11:45] (current)
krakjoe accepted
Line 3: Line 3:
   * Date: 2016-11-17   * Date: 2016-11-17
   * Author: krakjoe   * Author: krakjoe
-  * Status: Under Discussion+  * Status: Accepted
   * First Published at: http://wiki.php.net/rfc/abolish-narrow-margins   * First Published at: http://wiki.php.net/rfc/abolish-narrow-margins
  
Line 11: Line 11:
  
 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. 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. 
  
 ===== Proposal ===== ===== Proposal =====
Line 18: Line 16:
 RFC's come in the following two categories: RFC's come in the following two categories:
  
 +  * Proposals to make changes to PHP
   * Proposals to amend or create policy documents   * 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 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.
  
-This change means that the main vote in any RFC must have a super majority. +If this RFC is accepted, the original [[rfc:voting|voting RFC]] will be amended as per the Normative Text section of this RFC.
- +
-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. These rules shall apply to any RFC whose vote ends after this RFC is accepted, should this RFC be accepted.
  
-==== Normative text ==== +==== Normative Text ====
- +
-If this RFC is accepted, the original [[rfc:voting|voting RFC]] will be amended as follows.+
  
 Under the "Required Majority" heading, the following text is **REMOVED**: Under the "Required Majority" heading, the following text is **REMOVED**:
Line 51: Line 36:
  
 <blockquote> <blockquote>
-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 multiplied by two must be greater than or equal to the number of No votes.+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 options and may be decided by simple plurality. This means that the voting option with the most votes wins. (In the unlikely case that there is not a single option with most votes, the question will have to be resolved through some other way.)+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. 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.
Line 63: Line 48:
  
 A straight yes/no vote, 2/3 super majority required to pass. A straight yes/no vote, 2/3 super majority required to pass.
 +
 +<doodle title="Adopt the changes in this proposal?" auth="krakjoe" voteType="single" closed="true">
 +   * Yes
 +   * No
 +</doodle>
 +
 +Voting started on Friday 8th February, finishes Friday 22nd February.
  
 ===== Discussion Topics ====== ===== 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 less contributions, we want clearer outcomes.+  * 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 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 change who can vote: this is not the topic of this RFC.
rfc/abolish-narrow-margins.1549469589.txt.gz · Last modified: 2019/02/06 16:13 by nikic