rfc:voting2017

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:voting2017 [2017/09/11 12:43] – More updates zeevrfc:voting2017 [2019/01/31 13:39] (current) zeev
Line 1: Line 1:
-====== PHP RFC: Voting ====== +====== PHP RFC: RFC Workflow & Voting (2019 update) ====== 
-  * Version: 2.0.0001 +  * Version: 2.0.0002 
-  * Date: 2017+  * Date: 2019
   * Author: Zeev Suraski <zeev@php.net>   * Author: Zeev Suraski <zeev@php.net>
-  * Status: Draft (or Under Discussion or Accepted or Declined)+  * Status: Under Discussion
   * First Published at: http://wiki.php.net/rfc/voting2017   * First Published at: http://wiki.php.net/rfc/voting2017
  
Line 11: Line 11:
  
 Specifically, this RFC does that via: Specifically, this RFC does that via:
-  * Clarifying and redefining voting thresholds +  * Redefining and clarifying voting thresholds 
-  * Clarifying and redefining voting workflows +  * Redefining and clarifying voting workflows 
-  * Clarifying and redefining voting eligibility+  * Redefining and clarifying voting eligibility
  
  
Line 36: Line 36:
   * **RFC**: Request For Comments for a proposed Change to PHP or for a PHP Packaging Decision, published on http://wiki.php.net/rfc/.   * **RFC**: Request For Comments for a proposed Change to PHP or for a PHP Packaging Decision, published on http://wiki.php.net/rfc/.
  
-  * **Implementation Decisions:**  Decision regarding the technical implementation of PHP or any of its bundled extension, that do not have any impact on end users (with the exception of performance improvement). +  * **Implementation Decisions:**  Decisions regarding the technical implementation of PHP or any of its bundled extension, that do not have any impact on end users (with the exception of performance improvement).  Explicitly, these **do not include** added, altered, removed or deprecated functionality.
- +
-  * **Release Manager(s)**+
  
   * **PHP**:  The PHP package in source code or binary form, that are available on the main downloads page at http://www.php.net   * **PHP**:  The PHP package in source code or binary form, that are available on the main downloads page at http://www.php.net
Line 50: Line 48:
 **Changes to PHP** must be discussed ahead of inclusion on Internals (see RFC Workflow section below), and win a vote by at least a 2/3 (two thirds) majority of Eligible Voters.  The rationale for this super-majority requirement is simple - the cost of undoing Changes to PHP (or in the case of removal/deprecation - the cost of doing them) is substantial, and typically requires end users to actively work to change their apps so that they can still run.  Since we strive to minimize these occurrences, we must be as certain as possible that we're doing the right thing, and not rely on an incidental simple majority. **Changes to PHP** must be discussed ahead of inclusion on Internals (see RFC Workflow section below), and win a vote by at least a 2/3 (two thirds) majority of Eligible Voters.  The rationale for this super-majority requirement is simple - the cost of undoing Changes to PHP (or in the case of removal/deprecation - the cost of doing them) is substantial, and typically requires end users to actively work to change their apps so that they can still run.  Since we strive to minimize these occurrences, we must be as certain as possible that we're doing the right thing, and not rely on an incidental simple majority.
  
-**PHP Packaging Decisions** must also be discussed ahead of time on Internals, and must also win a vote - but given their substantially smaller long term impact, it's sufficient for them to win a simple majority (>50.0%).+**PHP Packaging Decisions** must also be discussed ahead of time on Internals, and must go through a vote.  However, unlike Changes to PHP, these decisions are a matter of preference preference that can be changed with little or no consequences for future versions.  Given their shorter term impact and relative low reversal costs, a simple majority is sufficient (>50.0%, or in the case of multiple choice - the options that wins the most votes). 
  
-**Implementation Decisions** generally do not require voting, but with the exception of small, tactical decisions (such as fixing a bug with just a few lines of code) - developers are still encouraged to bring it up for discussion on Internals.  As far as Implementation Decisions are concerned, the active maintainers of the particular piece of code (as reflected via source control) will have the jurisdiction.  Please note that Implementation Decisions explicitly do not include such decisions that have an impact on end user functionality, or that degrade performance in a noticeable way.  Such decisions are considered Changes to PHP, and must follow the rules above.+**Implementation Decisions** as defined above do not require voting, as they don't have an impact on end users.  However, developers are still encouraged to bring implementation decisions up for discussion on Internals, especially ones dealing with more fundamental parts of PHP, or ones which involve substantial refactoring.  As far as Implementation Decisions are concerned, the active maintainers of the particular piece of code (as reflected via source control) are the ones who have the jurisdiction to take them. 
 + 
 +Please note that Implementation Decisions explicitly do not include such decisions that have an impact on end user functionality, or that degrade performance in a noticeable way.  Such decisions are considered Changes to PHP, and must follow the rules above.
  
 ==== RFC Workflow ==== ==== RFC Workflow ====
  
-=== Authoring ===+=== Authoring Stage ===
  
-One or more people who are an Eligible Voter or that otherwise has access to the PHP Wiki may submit an RFC on http://wiki.php.net/rfc/ The authoring period is unlimited, and an RFC can exist on the PHP Wiki without any discussion for as long as the authors choose. +One or more people who are an Eligible Voter or that otherwise has access to the PHP Wiki may submit an RFC on http://wiki.php.net/rfc/ The authoring period is unlimited, and an RFC can exist on the PHP Wiki without any discussion for as long as the authors choose.
  
-=== Discussion Period ===+Author(s) should strive to have the RFCs self explanatory as much as possible, and seriously consider - and address - all possible implications associated with the acceptance of the RFC. 
 + 
 +== Targeted Version(s) == 
 +In RFCs dealing with Changes to PHP, the author(s) should designate which version(s) of PHP they intend to implement the changes for.  Typically, this would either be the next minor version or the next major version. 
 + 
 +== Patches == 
 +RFCs that deal with Changes to PHP must be accompanied with a patch, that demonstrates that the feature can be properly implemented in a reasonable way.  The patch may still be modified (or even completely rewritten) even if the RFC is accepted - the goal in having it is both as a proof of concept, as well as a default implementation even if no further work is done by the author(s) or any other volunteers. 
 + 
 +== Voting Options == 
 +As a part of authoring, the Voting Options must be made clear. 
 + 
 +For RFCs dealing with Changes to PHP, the voting choice must be a simple 'Support' or 'Oppose' the acceptance of the RFC. 
 + 
 +For RFCs dealing with PHP Packaging Decisions, the voting options would depend on the proposal.  For a change proposal, the options would similarly be 'Support' or 'Oppose' In case of choosing between multiple options (e.g., name the next PHP version 6.0 or 7.0) - the RFC should simply list the available options. 
 + 
 +== Secondary Votes == 
 + 
 +Secondary votes are votes about potential options for an RFC that deals with Changes to PHP.  While secondary votes are discouraged, they are allowed - e.g., in have a base support/oppose vote for the acceptance of a feature, and then a choice between two flavors of it.  Secondary Votes that can have a substantial influence on the acceptance of a feature are strongly discouraged, and should be separated into a different RFC. 
 + 
 + 
 +== Grouped Votes == 
 + 
 +Grouping of loosely related topics into one RFC (such as a list of features for deprecation in a given PHP version) is allowed for the sake of simplicity - but would be considered as separate RFCs as far as voting rules are concerned (see Voting Stage below). 
 + 
 +=== Discussion Stage ===
 Changes to PHP and PHP Packaging Decisions have substantial influence on PHP and its userbase, and it is therefore important to discuss them thoroughly before they are accepted or rejected.  When the author(s) believe that the RFC is ready, it must be brought up by the author(s) for discussion on Internals, by sending an email to it with the following subject line (for an imaginary RFC titled 'Foo Bar Baz'): Changes to PHP and PHP Packaging Decisions have substantial influence on PHP and its userbase, and it is therefore important to discuss them thoroughly before they are accepted or rejected.  When the author(s) believe that the RFC is ready, it must be brought up by the author(s) for discussion on Internals, by sending an email to it with the following subject line (for an imaginary RFC titled 'Foo Bar Baz'):
  
Line 67: Line 91:
 The email body itself must include a link to the RFC (http://wiki.php.net/rfc/foobarbaz). The email body itself must include a link to the RFC (http://wiki.php.net/rfc/foobarbaz).
  
-In order to ensure sufficient time for a thorough discussion, a mandatory two week discussion period is required, and the RFC may not move forward to the Voting stage before it passes.  Furthermore - if there is still active discussion at the end of the two week period, the discussion period may be extended for an additional two weeks - up to a maximum of four weeks.  The rationale behind the maximum week discussion period is twofold - longer discussion periods are rarely productive;  The main case where longer discussion periods are productive is if substantial changes are made to the RFC - which would sensibly require moving back to the Authoring stage and going through a new Discussion Period.  Secondly - it'designed to avoid a long gap between when an RFC is discussed and when it is voted upon.+In order to ensure sufficient time for a thorough discussion, a mandatory two week discussion period is required, and the RFC may not move forward to the Voting stage before it passes.   
 +If there is still active discussion towards the end of the mandatory 2 week period, the discussion period must be extended by an additional weeks (4 weeks in total). 
 +After the initial weeks, if there is still active discussion - it'up to the author(s) to decide whether they'd like to extend the discussion by an additional 2 weeks, or move to the Voting Stage.
  
-Once the author(s) believe that the discussion has concluded (and no sooner than 2 weeks since its introduction on Internals and no later than 4 weeks since it) - the authors must either proceed to the Voting stage, move back to the Authoring stage (which will require a new Discussion Period), or abandon the RFC.+Note that in order to ensure predictability - the Discussion Stage may only be increased in 2 week increments.
  
 +Once the author(s) believes that no additional extensions will be necessary, and assuming they'd like to move forward with the RFC, they must announce to Internals that the Discussion Stage will end at least 2 days before it does.  This can be done under the same discussion thread for the RFC.  If discussion resumes after that message is sent, the Discussion Stage should/may be extended per the same rules above.
 +
 +At any point, the author(s) may decide to pull the RFC back into the Authoring Stage (which will require a new Discussion Stage).
 +
 +== Changes to the RFC ==
 +
 +Any change to the RFC (to the proposal itself, not the meta data around it) will automatically extend the discussion period to end at least 1 week after the change was made (if the period was set to end more than 1 week after the change already, no extension is necessary).
 +
 +Substantial changes to the RFC - such as adding, changing or removing substantial functionality from it - require a restart of the Discussion Period.
 +
 +If, due to feedback, the author(s) make substantial changes to the RFC (add, alter or remove substantial functionality) - and the Discussion Stage has to end at least 1 week after these changes are made and announced on Internals. This is in order to avoid last minute changes to an RFC with insufficient time
 +
 +=== Voting Stage ===
  
-=== Voting === 
  
 In this stage, Eligible Voters may cast their votes based on the voting options of the RFC. In this stage, Eligible Voters may cast their votes based on the voting options of the RFC.
-When the author(s) decide to move to this stage (following the workflow in the Discussion Period above), they must send an email to Internals with the following subject line (for an imaginary RFC titled 'Foo Bar Baz'):+ 
 +When the author(s) decide to move to this stage (following the workflow in the Discussion Stage above), they must send an email to Internals with the following subject line (for an imaginary RFC titled 'Foo Bar Baz'):
  
 Subject:  [RFC VOTE] Foo Bar Baz Subject:  [RFC VOTE] Foo Bar Baz
Line 83: Line 122:
 For all RFCs, the voting period is 1 week long period, and ends (implicitly) one week after the RFC went to a vote, at midnight UTC. For all RFCs, the voting period is 1 week long period, and ends (implicitly) one week after the RFC went to a vote, at midnight UTC.
  
 +Note:  Eligible Voters are allowed to vote in only a subset of the votes available in a given RFC, if they choose to.  For example, in an RFC with a Secondary Vote - a voter may choose to only cast a vote on the secondary vote, and not cast a vote on whether or not to support or oppose the acceptance of the RFC;  Or vice versa, and in the same manner with Grouped Votes.  The right to vote in each poll is independent of whether or not one voted for other polls, as well as which option was voted for in these other polls.
  
-=== Eligible Voters === 
  
-The following people are eligible to cast votes on RFCs: 
  
-  * People who have contributed to the php-src git repository, and;  More than 12 months have passed since there initial contributionand;  Have contributed at least 50 commits, and;  Changed more than 500 lines in the project (additions/deletions). +==== Post Vote Stage ==== 
-  * Members of PHP-FIG (as per http://www.php-fig.org/members/+ 
-  * Additional groups requires metrics:  PHP ManualPHP-QA?+When the voting time expires the poll must be closed for further voting.  Generallythe author(s) of the RFC should be the ones closing the poll, but if for whatever reason that isn't done - any other person with Wiki access may close the poll at that time. 
 + 
 + 
 +=== Acceptance Thresholds === 
 + 
 +For RFCs dealing with Changes to PHP - the threshold for acceptance is at least 2/3 (two thirds) of the votes.  For secondary votes in such RFCs - the threshold is a simple majority (the option with the highest number of votes wins). 
 + 
 +For RFCs dealing with PHP Packaging Decisions the threshold is a simple majority - the option with the most votes wins. 
 + 
 +For Grouped Votes - the threshold would be according to the nature of each change - each one that fits Changes to PHP would require a 2/3 majority, and ones fitting PHP Packaging Decisions would require simple majorities. 
 + 
 + 
 +=== Accepted RFCs === 
 + 
 +If the RFC clears the required majority it is considered Accepted.  At that stage, the author(s) should send an email to Internals, with the subject line: 
 + 
 +Subject:  [RFC ACCEPTED] Foo Bar Baz 
 + 
 +At that stage, the author(s) and/or others may proceed to implement the proposed changes/decisions. 
 + 
 +Changes to PHP should be implemented in coordination with the respective maintainers of the affected areas in the code.  Note that the approval achieved with a vote is for the described feature and not necessarily any accompanied patch The final patch may be substantially different than the one in the RFC, as long as it still implements the same approved functionality. 
 + 
 +=== Rejected RFCs === 
 + 
 +In case an RFC does not reach the required majority it is considered Rejected.  At that stage, the author(sshould send an email to Internals, with the subject line: 
 + 
 +Subject:  [RFC REJECTED] Foo Bar Baz 
 + 
 +If the author(s), or others, are still interested in pursuing it they may do so, but only after a mandatory 6 month Hibernation Period.  Once that period is overthe RFC may go back to the Discussion Stage.  Making changes to the RFC that will reflect feedback that accumulated during the prior Discussion Stage and Voting Period is highly recommended, but not mandatory. 
 + 
 +RFCs that are substantially similar to the rejected RFC (deal with the same topic, and provide a similar proposal) are subjected to the same mandatory 6 month Hibernation Period. 
 + 
 +RFCs that targeted the next mini version, and are moved back to the Discussion Stage after a Hibernation Period, may not target that same mini version but only the one after it.  RFCs that target the next major version may still target it after Rejection and resumption of the Discussion Stage.
  
  
 === No Discussion/Voting Periods === === No Discussion/Voting Periods ===
  
-Based on global common vacation periods that affect a substantial subset of the participants in the PHP project, authors should avoid having discussion and voting periods take place during August or the second half of December.  If for whatever reasons an RFC discussion/voting period slip into August or late December, the RFC must move back to the Authoring stage until September/January respectively - and then go through a renewed Discussion Period.+Based on global common vacation periods that affect a substantial subset of the participants in the PHP project, authors should avoid having discussion and voting periods take place during August or the second half of December.  If for whatever reasons an RFC discussion/voting period slip into August or late December, the RFC must move back to the Authoring stage until September/January respectively - and then go through a renewed Discussion Stage.
 In addition, RFC author(s) are encouraged to be sensitive to periods with intense conference activities and avoid overlapping with them as much as possible. In addition, RFC author(s) are encouraged to be sensitive to periods with intense conference activities and avoid overlapping with them as much as possible.
  
  
-===== Proposed PHP Version(s) ===== +=== Restarting Polls ===
-List the proposed PHP versions that the feature will be included in.  Use relative versions such as "next PHP 7.x" or "next PHP 7.x.y".+
  
-===== RFC Impact =====+Generally, author(s) should only move RFCs that they feel very comfortable with to the Voting Stage.  However, there have been cases in the past where author(s) wanted to either withdraw the vote, or make minor changes to the RFC and restart it.
  
 +In case of a minor oversight or minor change that the author(s) feel is absolutely necessary, they may request to restart the vote by sending an email to Internals, with the subject line:
  
-===== Open Issues ===== +Subject:  [RESTART VOTE REQUEST] Foo Bar Baz
-Make sure there are no open issues when the vote starts!+
  
-===== Future Scope ===== +And explain which changes they intend to make to the RFC.  Since there is no way to quantify what constitutes 'minor'if more than 5 Eligible Voters say that they consider the changes to be substantial, the vote may not be restarted.  Voters should only do so in good faith.  If, however, after 2 days (48 hours) there are fewer than 5 such Eligible Voters, the author(s) may make the changes to the RFC, and restart the poll (discarding all previous votes).  During the time when the request is announced, and until it is accepted - the poll must remain open.
-This sections details areas where the feature might be improved in futurebut that are not currently proposed in this RFC.+
  
-===== Proposed Voting Choices ===== +If a request to restart is rejected, the author(s) may choose to either conclude the Voting Stage, or Withdraw the vote.
-Include these so readers know where you are heading and can discuss the proposed voting options.+
  
-State whether this project requires a 2/3 or 50%+1 majority (see [[voting]])+=== Withdrawing Votes ===
  
-===== Patches and Tests ===== +Withdrawing votes is not encouraged, but allowed;  The author(s) may announce to Internals that they're withdrawing the vote, at which point the results of the poll are canceled, and the RFC will be considered 'Withdrawn' Withdrawn RFCs are subject to the exact same rules as Rejected RFCs (see above).
-Links to any external patches and tests go here.+
  
-If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed. 
  
-Make it clear if the patch is intended to be the final patch, or is just a prototype.+==== Eligible Voters ====
  
-For changes affecting the core languageyou should also provide patch for the language specification.+The following people are eligible to cast votes on RFCs: 
 + 
 +  * People who have contributed to the php-src git repositoryand;  More than 12 months have passed since their initial contribution, and;  Have contributed at least 25 commits, and;  Added or modified more than 500 lines of code in the project.  As of Sep 14 2017, this is group of 175 developers.  See Appendix A below. 
 +  * Members of PHP-FIG (as per http://www.php-fig.org/members/
 +  * Major PHP Manual contributors (metrics?
 +  * Additional groups - PHP-QA? 
 + 
 + 
 +== Grandfathering of Current Voters == 
 + 
 +To allow for a smooth transition into this new eligibility system, users who have voted in at least 3 php.net polls between July 1, 2016 and June 30, 2017, and do not otherwise qualify as Eligible Voters under this RFC - will temporarily be considered Eligible Voters.  This temporary status will remain in effect until October 31, 2018.  Such grandfathered voters can retain Eligible Voters status by qualifying into one of the above-mentioned groups during that time. 
 + 
 + 
 +===== Open Issues ===== 
 +  * Mandatory 'hibernation' after a rejected/withdrawn vote  **DONE** 
 +  * Targeted version  **DONE** 
 +  * Require a patch for Changes to PHP?  **DONE** 
 +  * Partial 'grandfathering' of people currently eligible to vote?  **DONE** 
 +  * How do we vote on this one? 
 +  * Do we want to exempt additions of functionality into 'namespaced', non core extensions from a vote?  E.g. a new oci8_*() function, or a new ext/mysqli method?  (only additional functionality, not change/removal/deprecation) 
 +  * Do we want to have a minimal Quorum on certain types/all votes? 
 +  * Should there be a higher threshold for permanent voting eligibility, and a lower one for time-limited voting eligibility? 
 +  * Plenty more, I'm sure... 
 + 
 +===== Proposed Voting Choices ===== 
 +Approve/Reject.
  
-===== Implementation ===== 
-After the project is implemented, this section should contain  
-  - the version(s) it was merged to 
-  - a link to the git commit(s) 
-  - a link to the PHP manual entry for the feature 
-  - a link to the language specification section (if any) 
  
 ===== References ===== ===== References =====
-Links to external references, discussions or RFCs 
  
-===== Rejected Features ===== +[[https://wiki.php.net/rfc/voting|The original Voting RFC]] 
-Keep this updated with features that were discussed on the mail lists.+ 
 +[[https://wiki.php.net/gitstats_09_17|Git Statistics for the PHP project, Sep 2017]] - relevant stats are 'insertions' and 'commits' 
rfc/voting2017.txt · Last modified: 2019/01/31 13:39 by zeev