How PHP RFCs Work

An RFC page is evidence that somebody proposed and discussed a change. It is not evidence by itself that the change was accepted, implemented, or released.

The Three Main Phases

The current PHP feature-proposal policy describes initiation, discussion, and voting phases.

Initiation

An author creates an RFC on the PHP wiki and announces the official discussion on the PHP internals mailing list. The proposal should explain the problem, behavior, compatibility effects, alternatives, implementation plan, and proposed target version.

Informal discussion may happen first, but it does not replace the formal proposal process.

Discussion

Contributors review the semantics, syntax, backward compatibility, implementation, tests, documentation, and maintenance cost. Authors can update the RFC in response.

Current policy applies cooldown periods after substantive changes:

• a major change starts a 14-day cooldown
• a minor change starts a 7-day cooldown
• editorial corrections do not start a cooldown

The minimum discussion time is therefore 14 days when no later substantive changes reset or extend the wait. Discussion can continue longer, and active unresolved discussion should not be cut off merely because a minimum has elapsed.

Voting

Before opening a vote, authors announce an intent to vote in the discussion thread. Current policy requires that message at least 2 days and no more than 7 days before voting begins, with no active cooldown or substantive unresolved discussion.

The vote is announced separately and remains open for at least 14 days and no more than 28 days. The RFC records when voting ends.

How Acceptance Is Calculated

The primary vote asks whether to implement the proposal. Its options are Yes, No, and Abstain.

Acceptance requires a two-thirds majority among Yes and No votes. Abstain records an eligible voter's decision not to choose either side and is excluded from that calculation.

Examples:

• 10 Yes, 5 No, and 4 Abstain passes because Yes is twice No
• 9 Yes, 5 No, and 20 Abstain does not pass because 9 is less than 10

Secondary votes can choose implementation details. Their voting method and thresholds must be declared, and their results matter only if the related primary proposal is accepted.

Voting eligibility is governed by the PHP project's rules. An RFC is not a public opinion poll, and popularity on social media does not replace the recorded vote.

Read The Status Carefully

Common states include:

• Draft: an early proposal not yet formally announced
• Under discussion: formally opened for internals discussion
• Voting: eligible voters are currently deciding it
• Accepted: the proposal passed its required vote
• Declined: the proposal did not pass
• Implemented: accepted code was merged and the RFC records the target version

Older pages and process RFCs may use labels differently. Read the page's status, vote dates, result, implementation section, and changelog together.

Accepted Does Not Mean Released

A proposal can pass before its implementation is complete. Implementation may reveal an issue that requires an erratum, follow-up discussion, or another RFC. Code must still be reviewed, tested, merged into an eligible branch, documented, and included in a release.

To determine whether an application can use a feature, verify:

1. the RFC was accepted
2. the implementation was merged
3. the RFC or source history identifies the PHP version
4. the PHP manual and migration guide document the behavior
5. the application's actual runtime is that version or newer

The release notes and manual are more useful deployment evidence than an accepted proposal alone.

RFCs Can Cover More Than Syntax

PHP RFCs may propose:

• language syntax and semantics
• functions, classes, attributes, or extensions
• deprecations and removals
• release schedules
• naming and compatibility policies
• project governance or development process

Not every bug fix or implementation detail needs an RFC. Maintainers use the project's contribution and policy rules to decide which changes require formal approval.

Who Makes The Decision

The PHP project conducts RFC discussion and voting through PHP internals under its policies. Companies, framework projects, conference audiences, and the PHP Foundation can fund work, provide expertise, or participate through eligible contributors, but they do not independently declare a language RFC accepted.

This distinction matters when reading announcements. Sponsorship of an implementation is not the same as approval of the proposal.

How To Evaluate An RFC

When reading an RFC, ask:

• What concrete problem does it solve?
• What code changes for users?
• Which edge cases are specified?
• Is existing code reinterpreted or broken?
• What alternatives were rejected, and why?
• Is there an implementation and test plan?
• What is the target version?
• What was the final vote and threshold?
• Was the implementation merged?
• Does the released manual match the proposal?

Also inspect the RFC's change history. Examples copied from an early revision may no longer describe the text that was voted on.

Following Future PHP Changes

Use the PHP RFC index to discover proposals, then follow links to the official discussion, vote, implementation commits, migration guides, and manual pages. Separate speculative drafts from features that application code can rely on.

When planning an upgrade, base decisions on a released PHP branch and its migration guide. RFCs provide design history and rationale, but released behavior is the compatibility contract that matters to the application.

What To Remember

A PHP RFC moves through formal initiation, discussion, and voting. Primary acceptance needs a two-thirds Yes-to-No result under current policy, while abstentions do not affect that calculation. Passing a vote is not the end: implementation, merge, documentation, and release determine when developers can use the feature.

Before moving on, make sure you can explain why an accepted RFC may still be unavailable in production and which records you would check to establish its real status.