Here are some personal observations and suggestions that show how I
have seen feature acceptance and the RFC process work in
practice. These notes augment the steps in How To Create an RFC. I
hope they help set expectations about the PHP RFC process and feature
acceptance in the PHP language.
Before starting an RFC, review existing RFCs and search the
mail list archives for similar ideas. Use this information to
explain what your RFC will bring to the language.
If you're new to PHP core development, mail the "internals" mail
list to judge interest before you start your RFC. If you get no
reaction (this is likely) or positive reaction then create the RFC.
Core PHP developers with karma will know when they can skip this
Avoid presenting an RFC idea to the "internals" mail list with email
that begins "I don't know much about ... but ...". Do some research
There are many really good ideas for improving PHP, however
some of them are really tedious or technically risky or hard. If
you are about to email the "internals" mail list saying "someone
should do ...", then don't hit "Send". Work out how you could do it,
and then send a patch.
If the overall goals of PHP are not clear to you, you may not
be alone. However, as an RFC writer you need to learn the general
trajectory of the language and where web development is heading.
You then need to enthuse everyone with your feature and show what it
brings to the language.
Don't start an RFC (or mail list discussion) about standardizing PHP
function names and function argument orders. There are several
historical reasons why the functions are what they are (including
compatibility with underlying libraries), and many good reasons why
the change would be counter-productive causing more end-user
confusion, would lead to unmaintainable PHP engine code, and
generally be a waste of everyone's time when they could be doing
more interesting projects. This has been discussed ad
infinitum. Review previous discussions and feel free to fork PHP on
Your RFC should talk about all PHP areas that will be
affected: php.ini, different SAPIs, engine, extensions, etc. List
similar features. List similar features in other languages. Link
to references. Give an estimate of the actual positive impact to
user code. Put the proposed voting options in the RFC so they can
be included in its discussion. Include the proposed acceptance criteria
(2/3 or 50%+1 majority - see the original Voting RFC)
to avoid later argument.
Your RFC will be used to create the PHP documentation, so make its
sections re-usable. Explain concepts and details. Keep the RFC
technical and have plenty of examples.
Many current PHP RFCs don't contain enough detail, nor do they
capture the pros & cons that were discussed on the mail list. You
can, and should, do better than these RFCs.
An implementation is not mandatory while proposing an RFC but
it can help persuade people and help fine-tune the design. Note
that if you are unable to implement the RFC, and no one else
volunteers during the discussion period, then your RFC is unlikely
ever to be implemented.
Don't start an implementation too early. Get support for the
feature concept from the "internals" mail list before spending time on
coding - unless you want a learning experience.
If you do have an implementation, make it clear whether the
implementation is a simple prototype or is expected to be the final
code. This is specially important during the vote.
It's easy to get sidetracked by mail list trolling or well
intentioned but over-eager discussion. Take advice on board but
make sure your feature doesn't end up being designed by a committee.
Don't blame the "PHP core community" for derailing discussions when
the issues of non- code-contributors on the mail list are at fault.
For every user who wants a backwardly incompatible change to
PHP, there is a user who will scream that this will be disastrous to
them. As the RFC writer you need to walk the line between these
groups. At voting time, other people may see the line in a different
place than you do.
There is no need to respond to every discussion email
individually. You should batch up your responses and manage the
Don't get side tracked by how long it will take a feature to reach
end users. It will reach them eventually. You can always supply an
unofficial patch or maybe create a PECL extension for users of
current versions of PHP.
Don't let mail list discussion drag on too long. High levels of
discussion can be a symptom that an RFC is contentious. Having an
early vote about only the feature's concept can prevent
over-investment in an RFC and implementation.
With long, fragmented discussions, not everyone will read every
email. Update the RFC at regular intervals, and let people know
what has changed. Include the RFC URL in all your emails so anyone
dipping into a mail thread has a better chance of finding the RFC.
PHP is popular so you can often find support from "many" people for
cool language features. This doesn't mean those features are a
"good thing" for the language or its implementation.
There are multiple PHP communities. Don't interpret support
in one community as universal support. Listen carefully to the key
PHP developers on the "internals" mail list (they may not be the
ones doing the most discussion). They are the people who will
undoubtedly end up doing final integration of the feature (e.g. with
the op-code cache), fixing edge cases, and maintaining it in the
long term. They are the ones that have seen the PHP code base
complexity grow and become more difficult to maintain and extend.
Even if they like your idea, they may not be able to contribute time
and effort to make it stable.
The PHP core development community needs more end-users to
become core language developers but the barrier to entry is high
because of the complexity of the API, and because new features need
very careful integration with a complex language. See the point
above about existing developers not having enough time to support
every good idea. This just means you need perseverance to become a
core developer yourself. You can gain karma by being a regular code
contributor before starting your magnum opus RFC.
Some areas of PHP are complex or niche. Sometimes feature
suggestions will be greeted by an apparent lack of interest. Don't
be discouraged. This just means you need to take a stronger
leadership role, and also prove your credentials by first working on
the existing code base.
Keep your RFC updated with a summary of all the positive and
negative mail list discussion points and examples.
- This prevents arguments being rehashed on the mail list each year.
- Documentation will have clear use cases and show what does and
- Future RFC writers can see trends and build on previous ideas.
Before initiating a vote on your RFC, make sure the RFC
contains enough detail so that the vote is solely on the RFC
contents, not on any half-remembered or misinterpretable mail list
discussions. Un- (or badly) expressed intentions will only cause
you frustration when your RFC is rejected.
Don't leave any ambiguity in the RFC. As well as stating what
will be changed, also state what won't be changed. Ambiguity will
hurt the chances of a successful outcome because voters will be
unsure that the feature has been fully thought through. Make sure
there are no "Open Issues" in the RFC when voting. Make a decision
about the choices before opening the vote, or mark the issues
clearly as "Future topics for exploration".
Make sure any vote is clear about what is being voted on: is
it the idea, the specification, or the implementation? Is a
particular version of PHP being targeted? Is the implementation
going to be merged to the core language or made as a PECL extension?
Warn the "internals" mail list before starting the vote. This
notification gives you a chance to fine tune the wording of your
poll; this wording has caused contention in the past. The
approaching deadline may also cause last-minute RFC responses.
These may be significant enough to require further discussion.
Set a deadline for the vote (sadly the current voting RFC doesn't
require this). Having a deadline will forestall suggestions that a
vote was deliberately left open until it succeeded, and then closed
before the "negative" side could rally support.
During the voting period, it is common for people to continue
mail list discussion. You may need to halt the vote and address any
Prior to the end of the voting period, remind the mail list
that the vote is about to close.
Positive voting poll outcomes for RFs that are just "concepts"
can be interpreted as support for "good ideas" rather than being a
definitive guarantee that a feature will appear in a future version
of PHP. As a feature is later investigated and further discussed,
the early vote may become irrelevant. Similarly, where there is no
chance of an implementation being written, a positive poll outcome
is just an indicator of desire.
If your RFC is rejected, it is not the end of the world.
Sometimes ideas are submitted "before their time", and it takes an
acclimatization period for other developers to see their value. As
the core PHP developer base goes through natural turn-over,
revisiting an idea after a (long) period may result in different
appreciation. (This does not apply to some ideas, for example
standardizing function names). See the previous points about
becoming a core contributor - having karma goes a long way towards
getting an RFC accepted, not only because experienced contributors
know which RFCs are worth suggesting, and know how to make proposals
understandable. When your RFC is rejected, continue working with
the PHP core development community and revisit the RFC later.
You can always fork PHP from github.
In summary, the PHP development process is an organic process and
subject to flexibility. It is based heavily around users contributing
features that they require. This therefore requires high investment
from users who want change. Very rarely do PHP core developers have
bandwidth to take on external ideas, no matter how good they are.
Feature acceptance has to be pragmatic. The core PHP contributors
would love to see more people get commit karma and contribute to
This post has gone on long enough. My notes are current for the
time being. I'm sure there are observations or clarifications you can
make. If you want to add anything, please post a comment.