- ====== PHP RFC: Your Title Here ======
- Version: 0.1
- Date: 2023-05-03
- Author: Andreas Heigl, andreas@heigl.org
- Status: Draft
- First Published at: http://wiki.php.net/rfc/minimal_required_votes_on_rfcs
Quoting [[http://news.php.net/php.internals/71525|Rasmus]]:
> PHP is and should remain: > 1) a pragmatic web-focused language > 2) a loosely typed language > 3) a language which caters to the skill-levels and platforms of a wide range of users
Your RFC should move PHP forward following his vision. As [[http://news.php.net/php.internals/66065|said by Zeev Suraski]] "Consider only features which have significant traction to a large chunk of our userbase, and not something that could be useful in some extremely specialized edge cases [...] Make sure you think about the full context, the huge audience out there, the consequences of making the learning curve steeper with every new feature, and the scope of the goodness that those new features bring."
===== Introduction =====
Currently an RFC is considered accepted when 2/3rd of the submitted votes are in favour. Regardless of the total amount of votes. The purpose of this RFC is to set a minimum necessary amount of votes.
===== Proposal =====
RFCs describe and propose changes to the PHP language itself as well as the processes around it. Changes on that scale need a good backing in the community that creates PHP.
Currently there are over 1000 people that have voting rights, but only a handflul of RFCs have more than 50 votes on them. This seems like a mis-representation and means that a lot of RFCs have been accepted with less that 5% voter turnout. Meaning that the general interest in the majority of people eligible to vote seems to be very low.
There are two ways to mitigate that:
- Reduce the amount of people eligible to vote. THis RFC is not about that. The question whether voting rights should be gained on a temporary base has been raised some times already. Also proposaly to formalize gaining voting karma and to make the process of how to gain voting karma more transparent have been considered multiple times but have not yet been addressed in an RFC due to numerous reasons. It is not the goal of this RFC to change that!
2. Make sure that RFCs are accepted by at least a minimum amount of votes to show that there is a general interest in the currently active community. This is what this RFC is about. a To make sure that there is a general interest in the t
===== Proposed PHP Version(s) =====
As this is targeting the RFC process there is no reason that the implementation needs to wait for a specific version. Should this proposal be accepted it can be implemented immediately
===== RFC Impact ===== ==== To SAPIs ==== Describe the impact to CLI, Development web server, embedded PHP etc.
==== To Existing Extensions ==== Will existing extensions be affected?
==== To Opcache ==== It is necessary to develop RFC's with opcache in mind, since opcache is a core extension distributed with PHP.
Please explain how you have verified your RFC's compatibility with opcache.
==== New Constants ==== Describe any new constants so they can be accurately and comprehensively explained in the PHP documentation.
==== php.ini Defaults ==== If there are any php.ini settings then list: * hardcoded default values * php.ini-development values * php.ini-production values
===== Open Issues ===== Make sure there are no open issues when the vote starts!
===== Unaffected PHP Functionality ===== List existing areas/features of PHP that will not be changed by the RFC.
This helps avoid any ambiguity, shows that you have thought deeply about the RFC's impact, and helps reduces mail list noise.
===== Future Scope ===== This section details areas where the feature might be improved in future, but that are not currently proposed in this RFC.
===== Proposed Voting Choices ===== Include these so readers know where you are heading and can discuss the proposed voting options.
===== Patches and Tests ===== Links to any external patches and tests go here.
If there is no patch, make it clear who will create a patch, or whether a volunteer to help with implementation is needed.
Make it clear if the patch is intended to be the final patch, or is just a prototype.
For changes affecting the core language, you should also provide a patch for the language specification.
===== Implementation ===== After the project is implemented, this section should contain - the version(s) it was merged into - a link to the git commit(s) - a link to the PHP manual entry for the feature - a link to the language specification section (if any)
===== References ===== Links to external references, discussions or RFCs
===== Rejected Features ===== Keep this updated with features that were discussed on the mail lists.