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/13 10:17] – Add more open issues 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 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 go through a vote - but given their substantially smaller long term impact, a simple majority is sufficient (>50.0%, or in the case of multiple choice - the options that wins the most votes).+**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** 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.
  
-**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.+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 ====
Line 103: Line 103:
 == Changes to the RFC == == 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.+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. Substantial changes to the RFC - such as adding, changing or removing substantial functionality from it - require a restart of the Discussion Period.
Line 123: Line 123:
  
 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. 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.
 +
 +
 +
 +==== Post Vote Stage ====
 +
 +When the voting time expires - the poll must be closed for further voting.  Generally, the 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.
  
  
Line 136: Line 142:
 === Accepted RFCs === === Accepted RFCs ===
  
-If the RFC clears the required majority it is considered Accepted, the author(s) and/or others may proceed to implement the proposed changes/decisions.+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. 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 === === Rejected RFCs ===
  
-In case an RFC does not reach the required majority it is considered Rejected.  If the author(s) are still interested in pursuing it - they may do so, but only after a mandatory 6 month Hibernation Period.  Once that period is over, the 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.+In case an RFC does not reach the required majority it is considered Rejected.  At that stage, the author(s) should 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 over, the 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 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 Rejection, 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.+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.
  
  
Line 175: Line 190:
 The following people are eligible to cast votes on RFCs: 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 contribution, and;  Have contributed at least 50 commits, and;  Added or modified more than 500 lines of code in the project.  See Appendix A below.+  * People who have contributed to the php-src git repository, and;  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 a group of 175 developers.  See Appendix A below.
   * Members of PHP-FIG (as per http://www.php-fig.org/members/)   * Members of PHP-FIG (as per http://www.php-fig.org/members/)
-  * Additional groups - requires metrics:  PHP Manual, PHP-QA?+  * Major PHP Manual contributors (metrics?
 +  * Additional groups - PHP-QA?
  
  
Line 185: Line 201:
  
  
- 
-==== Appendix A:  Current git stats ==== 
- 
-As of the time of writing, the 
 ===== Open Issues ===== ===== Open Issues =====
   * Mandatory 'hibernation' after a rejected/withdrawn vote  **DONE**   * Mandatory 'hibernation' after a rejected/withdrawn vote  **DONE**
Line 195: Line 207:
   * Partial 'grandfathering' of people currently eligible to vote?  **DONE**   * Partial 'grandfathering' of people currently eligible to vote?  **DONE**
   * How do we vote on this one?   * 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?   * 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?   * Should there be a higher threshold for permanent voting eligibility, and a lower one for time-limited voting eligibility?
Line 204: Line 217:
  
 ===== References ===== ===== References =====
 +
 [[https://wiki.php.net/rfc/voting|The original Voting RFC]] [[https://wiki.php.net/rfc/voting|The original Voting RFC]]
  
 +[[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