PHP RFC: PHP Technical Committee
- Version: 1.0
- Date: 2023-03-03
- Author: Jakub Zelenka (bukka@php.net), Larry Garfield (larry@garfieldtech.com)
- Status: Declined
Introduction
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.
Proposal
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.
Definitions
The text contains various terms that need further clarification to prevent future wording dispute. Here are their definitions:
- php-src - Source code in https://github.com/php/php-src/.
- core developer - Anyone with write commit access to php-src.
- dev branch - php-src branch consisting of PHP- prefix and major and minor version number (e.g. PHP-8.2).
- maintainer - person responsible for core subsystem (e.g. extension or SAPI) that is listed in the php-src CODEOWNERS files.
- issue - php-src GitHub issue, including pull requests.
- process changes - Any changes impacting how the PHP project is managed.
- pull request - php-src GitHub pull request.
- RM - PHP release managers.
- user facing changes - Changes in PHP language and its semantics, user visible functions, classes, interfaces, constants and other user visible constructs.
- technical change - Any change to php-src that has no user-facing change, including the implementation details of an RFC-accepted user facing change.
- technical aspect - The portions of pull request or commit in php-src or commit to php-src master and dev branches that would be technical changes.
- technical decision - Decision on a technical aspect.
- TC - PHP Technical Committee.
To further clarify some of the defined terms, following subsection provides some useful examples.
Changes
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.
TC membership
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:
- Administering the election of the next set of TC members.
- Documenting and communicating any decisions of the TC.
- In case of a tie, the Secretary's vote will be considered the winning position.
Elections
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.
Vacancies
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.
Work flow
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.
- Any core developer (including a TC member) may ask for TC resolution of an issue by adding the label
tc-holdto it and @-mentioning the TC GitHub team. - An issue with the
tc-holdtag MUST NOT be merged. - The TC members will confer in whatever manner they deem most convenient, public or private or both.
- The TC SHOULD consult with relevant other individuals, including the core developers involved in the issue, Release Managers, and impacted maintainers as appropriate.
- The TC MUST deliver a decision within one month, via the mechanism described below.
- The TC Secretary MUST announce the decision and reasoning for it on the issue in question and remove the
tc-holdtag. - The decision of the TC is binding. That means a relevant change MUST NOT be merged until and unless it conforms with the TC's decision. Depending on the decision, the core developer involved may merge the issue, close it, or revise it accordingly.
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.
Decision process
User-facing changes
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.
Process changes
The RFC process will continue to be used for process changes, including changes to the role of the TC.
Technical changes
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:
- Whether a given pull request implements a feature or resolves a bug.
- Whether a given change qualifies as user-facing, and thus requires an RFC.
- Whether a given technical aspect or implementation approach is acceptable.
TC voting
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.
Proposed Voting Choices
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.