rfc:voting2017
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
rfc:voting2017 [2017/09/13 09:45] – - zeev | rfc:voting2017 [2019/01/31 13:27] – Update to 2019 zeev | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ====== PHP RFC: Voting ====== | + | ====== PHP RFC: RFC Workflow & Voting ====== |
- | * Version: 2.0.0001 | + | * Version: 2.0.0002 |
- | * Date: 2017 | + | * Date: 2019 |
* Author: Zeev Suraski < | * Author: Zeev Suraski < | ||
* Status: Draft (or Under Discussion or Accepted or Declined) | * Status: Draft (or Under Discussion or Accepted or Declined) | ||
Line 36: | Line 36: | ||
* **RFC**: Request For Comments for a proposed Change to PHP or for a PHP Packaging Decision, published on http:// | * **RFC**: Request For Comments for a proposed Change to PHP or for a PHP Packaging Decision, published on http:// | ||
- | * **Implementation Decisions: | + | * **Implementation Decisions: |
- | + | ||
- | * **Release Manager(s)** | + | |
* **PHP**: | * **PHP**: | ||
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. | **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. | ||
- | **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 |
+ | |||
+ | **Implementation Decisions** as defined above do not require voting, as they don't have an impact on end users. | ||
- | **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. | + | Please note that Implementation Decisions explicitly do not include such decisions that have an impact on end user functionality, |
==== 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. | 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. | ||
+ | |||
+ | |||
+ | |||
+ | ==== Post Vote Stage ==== | ||
+ | |||
+ | When the voting time expires - the poll must be closed for further voting. | ||
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/ | + | 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: | ||
+ | |||
+ | At that stage, the author(s) and/or others may proceed to implement the proposed changes/ | ||
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. | 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. | ||
=== Rejected RFCs === | === Rejected RFCs === | ||
- | In case an RFC does not reach the required majority it is considered Rejected. | + | In case an RFC does not reach the required majority it is considered Rejected. |
+ | |||
+ | Subject: | ||
+ | |||
+ | If the author(s), or others, | ||
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, | + | * People who have contributed to the php-src git repository, and; More than 12 months have passed since their initial contribution, |
* Members of PHP-FIG (as per http:// | * Members of PHP-FIG (as per http:// | ||
- | * Additional groups - requires metrics: | + | |
+ | | ||
Line 185: | Line 201: | ||
- | |||
- | ==== Appendix A ==== | ||
===== Open Issues ===== | ===== Open Issues ===== | ||
- | * How do we vote on this one? | ||
* Mandatory ' | * Mandatory ' | ||
* Targeted version | * Targeted version | ||
* Require a patch for Changes to PHP? **DONE** | * Require a patch for Changes to PHP? **DONE** | ||
* Partial ' | * Partial ' | ||
+ | * How do we vote on this one? | ||
+ | * Do we want to exempt additions of functionality into ' | ||
* 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, | ||
* Plenty more, I'm sure... | * Plenty more, I'm sure... | ||
Line 201: | Line 217: | ||
===== References ===== | ===== References ===== | ||
+ | |||
[[https:// | [[https:// | ||
+ | [[https:// | ||
rfc/voting2017.txt · Last modified: 2019/01/31 13:39 by zeev