PHP adds new features through RFCs, which get discussed on the internals mailing list and then put to a vote. The written rules for that process had fallen behind, and people were following plenty of conventions that were never written down. This RFC from Tim Düsterhus puts those unwritten rules into the official policy.
Why change it
The old policy didn't match what people actually did. That gap confused newer contributors, and because the rules were so vague, it also let some people argue that they could "bend the rules."
What the new policy says
The RFC asks voters to accept a change to the php/policies repository. The main points are:
- At least two weeks of discussion. Every RFC gets a minimum of two weeks, and this now covers RFCs that don't change the language, too.
- More time after changes. If the author changes the RFC text, the discussion period gets longer.
- Announce when changes are ready. Authors must post to the list when a change is ready for review.
- Restart quiet threads. If the discussion goes quiet for too long, the period gets extended.
- Warn before voting. Authors must send a "heads up" email before a vote starts.
- A clear vote email. The policy lists what the email that opens a vote has to include.
- No holiday endings. A vote can't end during the end-of-year holidays. It either gets extended or starts later.
The text grew during the discussion. It added a maximum length for votes, said an RFC can't change once voting starts, and let an author cancel a vote during its first 7 days.
What it means for you
Your PHP code doesn't change, since this is about how RFCs move from idea to vote. If you write or follow RFCs, the timeline is now written down, so you can see how long discussion must run and when a vote is allowed to start.
The vote
Accepted. Voting closed on November 20, 2025 with 24 in favor, 6 against and 1 abstaining, clearing the two-thirds majority it needed. The new policy has since been merged into the php/policies repository.