Skip to content
🚀 PHP 8.6 is coming — check out what's new
PHP News
Search

The RFC process

How a new PHP feature gets made

Every new function, syntax change and deprecation in PHP starts as an RFC: a written proposal that the people who build PHP discuss and then vote on. Here is how it works, without the jargon.

  1. Someone writes it down

    Draft

    Every change to the language starts as a written proposal on the PHP wiki, called an RFC ("Request for Comments").

    • Anyone can write one. They ask the internals mailing list for permission to edit the wiki, then fill in a standard template.
    • The template covers what would change, why it is worth doing, code examples, and what could break for existing code.
    • Many authors float the idea on the mailing list first to see whether anyone is interested. That early chat is encouraged, but it does not count toward anything.
    • A draft has not been announced yet, so it can change completely or quietly go nowhere.
    See the current drafts →

  2. It gets argued over

    Discussion

    The author announces the RFC on the internals mailing list with an email titled "[RFC]" plus the proposal's name. That starts the discussion.

    • Discussion lasts at least 14 days. People poke holes in it, suggest alternatives, and ask about edge cases.
    • Changes reset the clock. A change to how the feature actually works means another 14 days before a vote. New examples or clearer explanations mean 7 days. Fixing typos resets nothing.
    • There is no deadline. An RFC can stay in discussion for months, but if its thread goes quiet for six weeks it is considered stale, and picking it back up restarts a waiting period.
    See what is under discussion →

  3. It goes to a vote

    Voting

    When the author thinks every question has been answered, they give notice with an "Intent to Vote" email, then open the vote 2 to 7 days later.

    • Voting runs for at least 14 days and at most 28. Nothing can start or finish voting between December 17 and January 10, so holidays don't decide anything.
    • The RFC text is frozen once voting starts. If something serious turns up, the author can cancel within the first 7 days and go back to discussion.
    • Voters answer one main question: "Implement this feature as outlined in the RFC?" Yes, No, or Abstain.
    • Some RFCs have extra votes on details, such as the name of a function or which syntax to use. Those only count if the main vote passes.
    See what is in a vote →

  4. It passes, or it doesn't

    Accepted

    An RFC passes when it gets at least twice as many Yes votes as No votes, which is a two-thirds majority. Abstentions are ignored.

    • 8 Yes, 4 No and 9 Abstain passes: 8 is exactly twice 4.
    • 5 Yes, 3 No fails: it needed at least 6 Yes votes.
    • A declined RFC cannot come back to a vote for six months unless it changes substantially. Authors often come back with a "v2" RFC instead.
    See recently declined RFCs →

  5. It ships in PHP

    Implemented

    Accepted code is reviewed and merged into php-src, and the RFC is marked with the version it landed in.

    • New PHP versions come out every November. New features usually have to land before that year's beta around mid-August, so an RFC accepted in September often waits for the following year.
    • If a problem turns up while the code is being written, the author adds a correction note to the RFC. A big change can need a follow-up discussion, or even a new RFC.
    See accepted RFCs by version →

Who gets to vote?

Mostly people who have contributed code to PHP itself and have a php.net account. A small number of community representatives, such as lead developers of major frameworks and regulars on the internals list, can be given a vote as well. There are usually a few dozen votes on any one RFC.

You don't need a vote to have a say. The internals list is open to everyone, and a clear example of how a proposal would help or hurt your code carries weight in the discussion.