The Open Source project that develops the PHP language and its reference implementation uses an RFC process to discuss and vote on proposed changes. This was created mainly for user facing changes. It works well for that purpose but it is not that effective for deciding about purely technical changes that impact PHP internals and extension APIs. It is not clear how it should resolve technical conflicts between core developers.
This RFC proposes an introduction of the PHP Technical Committee (TC) that would decide about all technical aspects of php-src when there are disagreements between core developers.
The text contains various terms that need further clarification to prevent future wording dispute. Here are their definitions:
To further clarify some of the defined terms, following subsection provides some useful examples.
It is important to clarify difference between user facing change and technical changes. As it is defined, the technical change is any php-src change that is not a user facing change. However, the implementation of user facing change is still a technical change. Put another way, the definition of the user interface is user facing only, while the implementation itself is a technical change.
For example if there is a proposal to add accessors for PHP classes, then everything that is visible to user space like the constructs and their usage in PHP code is a user facing change. The actual C implementation and tests are a technical change.
The TC consists of five elected members. Any core developer is eligible to run for the TC. One member of the TC, selected by the TC members themselves, is the TC Secretary.
The TC Secretary is responsible for:
The election process takes place annually, concurrent with the election of the Release Managers in approximately March/April. (The exact date may vary year to year.) The sitting TC Secretary officially begins the process with a call for nominations. The nomination period lasts for one month.
During that week, any eligible core developer may self-nominate by posting to the Internals mailing list. If the candidate is paid to work on php-src or PHP extensions, they must state in their nomination which company or organization they work for to prevent potential conflicts of interest. Failure to do so will result in disqualification, as determined by the TC Secretary.
Once nominations are over, the voting process will begin. Eligible voters are the same as for any RFC.
If there are five or fewer nominees, there is no vote and all nominated individuals are elected.
If there are six or more nominees, a two week vote using the Single Transferable Vote method will take place. The five winning candidates at the end of the vote are elected.
The newly elected TC members will elect from their own number a TC Secretary by simple majority.
Any TC member may resign at any time via an email to the Internals mailing list. If the resigning member is the TC Secretary, then the TC will elect a new Secretary from its number.
Should a TC member become inactive for more than 30 days, the TC may declare that member's seat vacant, by a majority vote. If the vote passes, the TC member is removed.
If the number of TC members is reduced to three or fewer and there are more than two months until the next regularly scheduled election, the Secretary must call for a special election for the vacant seats. The election process is the same as for any other election, but the newly elected TC members will serve only until the next regular election.
Should the number of TC members fall to zero, the senior-most Release Manager of the latest stable release will step in to act as TC Secretary and immediately call for a new vacancy election.
The TC is primarily a reactive body, and is not expected to proactively search for issues.
Should a dispute or question about a change arise, the TC may be called on to resolve it.
tc-hold to it and @-mentioning the TC GitHub team.tc-hold tag MUST NOT be merged.tc-hold tag.
If an issue has been marked tc-hold for more than two weeks with no response or acknowledgement from the TC, the
developer SHOULD post to the Internals mailing list a notification of absence.
If a notification of absence receives no response from the TC or any member of it for 30 days, then the entire TC is automatically removed. New elections must then be immediately called as described above.
The election of a new TC will “reset the clock” on any outstanding tc-hold issues.
The RFC process will continue to be used for user facing changes. However, it will no longer be used for non-user-facing technical decisions.
TC members have no special role or authority in the RFC process.
The RFC process will continue to be used for process changes, including changes to the role of the TC.
As noted, the TC has no special role or authority on user-facing changes. The TC may, however, decide on the implementation of those features. In other words the TC can decide about implementation and C ABI and API but not about PHP API.
The TC SHOULD NOT block the merging of a user-facing change approved by the RFC process, unless the provided implementation would result in introduction of new bugs, side effects not mentioned in the RFC, significant performance penalties not mentioned in RFC, or if there is an equivalent implementation in progress that the TC finds more appropriate.
The TC SHOULD give due consideration and weight to previous decisions regarding technical aspects, either by the TC or by RFCs prior to the TC's creation. However, it is NOT REQUIRED to abide by them, and may make decisions as it sees best to ensure the quality and maintainability of the code at the time the decision is made.
Technical aspects on which the TC may make a decision include, but are not limited to:
Once an issue has been brought to the TC, the Secretary will facilitate a discussion period lasting two weeks or until all TC members have had time to offer their input, whichever comes first. Once the Secretary feels the issue has been sufficiently discussed, the Secretary will call a vote of the TC members. The vote will be private and conducted however the TC chooses.
The vote will last for two weeks or until all TC members have voted, whichever comes first. All votes are simple-majority, with no quorum on a binary question (which could be yes/no or either/or, depending on the situation, as determined by the Secretary). Members may explicitly abstain, and refraining from voting counts as an abstention. Abstentions do not count toward the result.
In case of a tie, the Secretary's vote will be considered the winning position.
Alternatively, if there is clear consensus among the TC members the Secretary may opt to skip the vote and report the consensus decision, provided all members have been given time to weigh in. Any member of the TC may require that a vote be held.
As per the voting RFC a yes/no vote with a 2/3 majority is needed for this proposal to be accepted.
Voting started on 2023-04-28 10:00 UTC and will end on 2023-05-12 10:00 UTC.