rfc:voting

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
rfc:voting [2018/02/26 16:45] – Fix internals email and minor misspelling carusogabrielrfc:voting [2019/04/22 06:53] (current) krakjoe
Line 1: Line 1:
 ====== Request for Comments: Voting on PHP features ====== ====== Request for Comments: Voting on PHP features ======
-  * Version: 1.0 +  * Version: 1.2 
-  * Date: 2011-06-05+  * Date: 2019-02-22
   * Author: Zeev Suraski, Pierre Joye, David Soria Parra   * Author: Zeev Suraski, Pierre Joye, David Soria Parra
   * Status: Accepted, [[rfc:voting:vote|Voting results]]   * Status: Accepted, [[rfc:voting:vote|Voting results]]
Line 32: Line 32:
 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 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 weekwhich can be extended when circumstances warrant it+Votes should be open for two weeks at minimumat the authors discretion this may be extended, for example during holiday periods.  
 + 
 +A valid voting period must be declared when voting is started and must not be changed during the vote.
  
 ===== Required Majority ===== ===== Required Majority =====
  
-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 proposalvs. 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'.+**Note:** This section has been amended by the [[rfc:abolish-narrow-margins|Abolish Narrow Margins RFC]]. 
 + 
 +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.
  
  
rfc/voting.1519663534.txt.gz · Last modified: 2018/02/26 16:45 by carusogabriel