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 [2011/07/12 18:15] – typo cyberscriberfc: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 18: Line 18:
 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. 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, he should recruit one of the members for help or request membership. +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. 
  
 ===== Discussion period ===== ===== Discussion period =====
  
-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. +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@lists.php.net, 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.  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. 
Line 28: Line 28:
 ===== Voting ===== ===== Voting =====
  
-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, he can decide not to move ahead to request a vote after the minimal period, but extend it as needed.  On the other hand, if he feels that the discussion is being derailed - he can always move ahead to a vote as long as the minimum discussion time elapsed.+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 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.
  
  
Line 43: Line 51:
 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: 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:
   * 6 months pass from the time of the previous vote, OR   * 6 months pass from the time of the previous vote, OR
-  * The author(s) make substantial changes to the proposal.  While it's impossible to put clear definitions on what constitutes 'substantial' changes, they should be material enough so that they'll significantly effect the outcome of another vote.+  * The author(s) make substantial changes to the proposal.  While it's impossible to put clear definitions on what constitutes 'substantial' changes, they should be material enough so that they'll significantly affect the outcome of another vote.
  
    
Line 51: Line 59:
  
 The proposal here is for two audiences to participate in the voting process: The proposal here is for two audiences to participate in the voting process:
-  * People with php.net SVN accounts that have contributed code to PHP +  * People with php.net VCS accounts that have contributed code to PHP 
-  * Representatives from the PHP community, that will be chosen by those with php.net SVN accounts+  * Representatives from the PHP community, that will be chosen by those with php.net VCS accounts
     * Lead developers of PHP based projects (frameworks, cms, tools, etc.)     * Lead developers of PHP based projects (frameworks, cms, tools, etc.)
     * regular participant of internals discussions     * regular participant of internals discussions
rfc/voting.1310494522.txt.gz · Last modified: 2017/09/22 13:28 (external edit)