rfc:voting2017

This is an old revision of the document!


PHP RFC: Voting

Introduction

This RFC amends and replaces https://wiki.php.net/rfc/voting with the main goals of being clearer, more concise, and with no ambiguities as much as possible.

Specifically, this RFC does that via:

  • Clarifying and redefining voting thresholds
  • Clarifying and redefining voting workflows
  • Clarifying and redefining voting eligibility

Background

Since the original Voting RFC was published back in 2011, it gradually became clear that the language in it is ambiguous, and in some cases - shortsighted. To name some examples:

  • The definition of 'who gets a vote' was very fluid
  • The definition of which votes require a 2/3 majority and which ones don't was very fluid
  • The voting workflow text was very terse - and left elements such as 'canceled votes' unhandled and open for interpretation
  • Even the definition of what requires a vote in the first place was not clear

Because of its many shortcomings, this RFC does not attempt to 'fix' the original Voting RFC, but rather rewrite it - factoring in the lessons learned in the last 6+ years.

Proposal

Definitions

  • Changes to PHP: Functionality that is added, changed, deprecated or removed from the PHP language, including any bundled extensions.
  • PHP Packaging Decisions: Decisions that deal with support timelines, release timelines or version numbering, but that do not otherwise impact the functionality of PHP or any of its bundled extensions.
  • 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).
  • 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
  • Internals: The PHP Internals mailing list, internals@lists.php.net.
  • Eligible Voters: People who are eligible to vote per the Eligible Voters section below.

General

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%).

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.

RFC Workflow

Authoring

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

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'):

Subject: [RFC] Foo Bar Baz

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 4 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's designed to avoid a long gap between when an RFC is discussed and when it is voted upon.

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.

Voting

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'):

Subject: [RFC VOTE] Foo Bar Baz

and include a link to the RFC (http://wiki.php.net/rfc/foobarbaz).

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.

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 contribution, and; Have contributed at least 50 commits, and; Changed more than 500 lines in the project (additions/deletions).
  • Members of PHP-FIG (as per http://www.php-fig.org/members/)
  • Additional groups - requires metrics: PHP Manual, PHP-QA?

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. 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)

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

Open Issues

Make sure there are no open issues when the vote starts!

Future Scope

This sections details areas where the feature might be improved in future, but that are not currently proposed in this RFC.

Proposed Voting Choices

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)

Patches and Tests

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.

For changes affecting the core language, you should also provide a patch for the language specification.

Implementation

After the project is implemented, this section should contain

  1. the version(s) it was merged to
  2. a link to the git commit(s)
  3. a link to the PHP manual entry for the feature
  4. a link to the language specification section (if any)

References

Links to external references, discussions or RFCs

Rejected Features

Keep this updated with features that were discussed on the mail lists.

rfc/voting2017.1505133836.txt.gz · Last modified: 2017/09/22 13:28 (external edit)