The PHP RFC process has been in place for a while, and users new to core PHP development are starting to use RFCs to propose desirable features. Here are some personal observations and suggestions that show how I have seen feature acceptance and the (newish) 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.

He lists the steps in the process from start to finish including things like:

• Avoid presenting an RFC idea to the "internals" mail list with email that begins "I don't know much about ... but ...". Do some research first.
• 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.
• 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.
• There is no need to respond to every discussion email individually. You should batch up your responses and manage the discussion intelligently.
• With long, fragmented discussions, not everyone will read every email. Update the RFC at regular intervals, and let people know what has changed.
• 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.
• During the voting period, it is common for people to continue mail list discussion. You may need to halt the vote and address any issues.

Obviously, there's a lot more to it than that - his post does a great job of letting you know what to expect and includes useful tips on helping you get your idea across.