rfc:voting2017
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:voting2017 [2017/09/11 09:16] – Initial updates zeev | rfc:voting2017 [2019/01/31 13:39] (current) – 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: | + | * Status: Under Discussion |
* First Published at: http:// | * First Published at: http:// | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | This RFC amends and replaces https:// | + | This RFC amends and replaces https:// |
Specifically, | Specifically, | ||
- | * Clarifying | + | * Redefining |
- | * Clarifying | + | * Redefining |
- | * Clarifying | + | * Redefining |
Line 30: | Line 30: | ||
==== Definitions ==== | ==== Definitions ==== | ||
- | * **RFC**: Request For Comments for a proposed Change | + | * **Changes |
- | * **Change to PHP: | + | * **PHP Packaging Decisions: |
- | * **PHP Packaging Decision:** | + | * **RFC**: Request For Comments for a proposed Change to PHP or for a PHP Packaging |
- | * **Implementation | + | |
+ | * **Implementation Decisions: | ||
+ | |||
+ | * **PHP**: | ||
+ | |||
+ | * **Internals**: | ||
+ | |||
+ | * **Eligible Voters**: | ||
==== General ==== | ==== General ==== | ||
- | Votes shall be had for | + | **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. |
- | Quarum | + | |
- | Affiliated projects | + | |
- | ===== Proposed | + | **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 |
- | List the proposed | + | |
- | ===== RFC Impact ===== | + | **Implementation Decisions** as defined above do not require voting, as they don't have an impact on end users. |
+ | Please note that Implementation Decisions explicitly do not include such decisions that have an impact on end user functionality, | ||
- | ===== Open Issues | + | ==== RFC Workflow |
- | Make sure there are no open issues when the vote starts! | + | |
- | ===== Future Scope ===== | + | === Authoring Stage === |
- | This sections details areas where the feature might be improved in future, but that are not currently proposed in this RFC. | + | |
- | ===== Proposed Voting Choices ===== | + | One or more people who are an Eligible Voter or that otherwise has access to the PHP Wiki may submit an RFC on http:// |
- | Include these so readers know where you are heading | + | |
- | State whether this project requires a 2/3 or 50%+1 majority | + | 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. |
- | ===== Patches and Tests ===== | + | == Targeted Version(s) |
- | Links to any external patches and tests go here. | + | In RFCs dealing with Changes to PHP, the author(s) should designate which version(s) of PHP they intend |
- | If there is no patch, | + | == Patches == |
+ | RFCs that deal with Changes to PHP must be accompanied with a patch, | ||
- | Make it clear if the patch is intended to be the final patch, or is just a prototype. | + | == Voting Options == |
+ | As a part of authoring, | ||
- | For changes | + | For RFCs dealing with Changes to PHP, the voting choice must be a simple ' |
+ | |||
+ | For RFCs dealing with PHP Packaging Decisions, the voting options would depend on the proposal. | ||
+ | |||
+ | == Secondary Votes == | ||
+ | |||
+ | Secondary votes are votes about potential options for an RFC that deals with Changes to PHP. While secondary votes are discouraged, | ||
+ | |||
+ | |||
+ | == 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. | ||
+ | |||
+ | Subject: | ||
+ | |||
+ | The email body itself must include a link to the RFC (http:// | ||
+ | |||
+ | 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 2 weeks (4 weeks in total). | ||
+ | After the initial 4 weeks, if there is still active discussion - it's 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. | ||
+ | |||
+ | 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 | ||
+ | |||
+ | 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 === | ||
+ | |||
+ | |||
+ | 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 Stage above), they must send an email to Internals with the following subject line (for an imaginary RFC titled 'Foo Bar Baz' | ||
+ | |||
+ | Subject: | ||
+ | |||
+ | and include a link to the RFC (http:// | ||
+ | |||
+ | 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. | ||
+ | |||
+ | |||
+ | |||
+ | ==== Post Vote Stage ==== | ||
+ | |||
+ | When the voting time expires - the poll must be closed for further voting. | ||
+ | |||
+ | |||
+ | === Acceptance Thresholds === | ||
+ | |||
+ | For RFCs dealing with Changes to PHP - the threshold for acceptance is at least 2/3 (two thirds) of the votes. | ||
+ | |||
+ | 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. | ||
+ | |||
+ | 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 | ||
+ | |||
+ | === Rejected RFCs === | ||
+ | |||
+ | In case an RFC does not reach the required majority it is considered Rejected. | ||
+ | |||
+ | Subject: | ||
+ | |||
+ | 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. | ||
+ | |||
+ | 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/ | ||
+ | |||
+ | 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. | ||
+ | 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. | ||
+ | |||
+ | |||
+ | === Restarting Polls === | ||
+ | |||
+ | Generally, author(s) should only move RFCs that they feel very comfortable with to the Voting Stage. | ||
+ | |||
+ | 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: | ||
+ | |||
+ | Subject: | ||
+ | |||
+ | And explain which changes they intend to make to the RFC. Since there is no way to quantify what constitutes ' | ||
+ | |||
+ | If a request to restart is rejected, the author(s) may choose to either conclude the Voting Stage, or Withdraw the vote. | ||
+ | |||
+ | === Withdrawing Votes === | ||
+ | |||
+ | Withdrawing votes is not encouraged, but allowed; | ||
+ | |||
+ | |||
+ | ==== 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 their initial contribution, | ||
+ | * Members of PHP-FIG (as per http:// | ||
+ | * 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. | ||
+ | |||
+ | |||
+ | ===== Open Issues ===== | ||
+ | * Mandatory ' | ||
+ | * Targeted version | ||
+ | * Require a patch for Changes to PHP? **DONE** | ||
+ | * 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? | ||
+ | * Should there be a higher threshold for permanent voting eligibility, | ||
+ | * Plenty more, I'm sure... | ||
+ | |||
+ | ===== Proposed Voting Choices ===== | ||
+ | Approve/ | ||
- | ===== Implementation ===== | ||
- | After the project is implemented, | ||
- | - 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:// |
- | Keep this updated with features that were discussed on the mail lists. | + | |
+ | [[https:// |
rfc/voting2017.txt · Last modified: 2019/01/31 13:39 by zeev