PHP RFC: PHP Technical Committee

• Version: 0.2
• Date: 2023-03-03
• Author: Jakub Zelenka, bukka@php.net
• Status: Draft

PHP uses its voting system to decide about changes to PHP. 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 API's. It is not clear how it should resolve conflicts on the technical basis between contributors that sometimes happen.

This RFC proposes an introduction of the PHP Technical Committee (TC) that would decide about all technical aspects of php-src. Specifically its main purpose is to decide about disagreements between contributors but it is not limited to that only.

The text contains various terms that need further clarification to prevent future wording dispute. Here are their definitions:

• contributor - Anyone who has already contributed to php-src.
• core developer - Anyone with write commit right to php-src.
• dev branch - php-src branch consisting of PHP- prefix and major and minor version number (e.g. PHP-8.2).
• issue - php-src GitHub issue.
• maintainer - person responsible for extension or SAPI that is listed in php-src EXTENSION file.
• php-src - Source code in https://github.com/php/php-src/.
• PR - Pull request.
• process changes - Any changes impacting the way how PHP project is managed and its bylaws.
• pull request - php-src GitHub pull request.
• RM - PHP release managers.
• technical aspect - Technical change of any issue or pull request in php-src or commit to php-src master and dev branches.
• technical descision - Decision on a technical aspect.
• technical change - Any php-src change excluding user facing changes. It covers also the implementation of user facing changes.
• TC - PHP Technical Committee.
• user facing changes - Changes in PHP languege, user visible funtions, classes, interfaces, constants and other user visible constructs.

To further clarify some of the defined terms, following subsection provides some useful examples.

It is important to clarify differnce 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. The meaning of that is that the part of the user facing change that defines the user interface is not 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 work flow for TC is following:

1. Any core developer can add label tc-hold on issue or pull request.
2. The core developer should mention the TC GitHub team to notify members of the TC.
3. The TC discusses the issue or pull request and vote on it (this can be done privately)
   • The TC should consult with maintainers if the issue / PR changes or impacts code maintained by the maintainer
   • The TC should consult with RM if the issue / PR is about classification of the self contained feature or a bug
4. The TC announce its decision and reasoning by commenting on the issue or pull request
5. The core developer will follow the decision which can mean (not limited to):
   • merging the issue / PR
   • closing / rejecting the issue / PR
   • making requested change to the PR

It should be noted that if the problem is with a specific commit, the core developer can create an issue specifying the problem and put label on it.

The TC decision should not take longer than month. If it takes longer than one month, the following work flow can be applied:

1. After a month of no response from the TC the core developer can send a formal notification to the internals mailing list.
2. If the notification is ignored for more than one month by the TC, the core developer can send a formal warning to the internals mailing list.
3. If the formal warning is also ignored for more than a month, then the core developer can call for new election of TC members
4. New election happen within a month.

There is a caveat that if the election happens due to yearly elections between any steps of the workflow above, the core developer needs to send a new notification after the elections and starts the workflow again.

The TC candidates nominate themself to become a TC member. They must be a core developers and should have a general knowledge about PHP internals. If the candidates are paid to work on php-src or PHP extensions, they must state in their nomination which company or organization they work for.

The TC shoudl be composed of 5 members. If there are not enough candiates, it can be composed of reduced number of members but it must have at least 3 members. The TC election of memebers will happen every year together with release managers selection. The RFC voting process using a single transferable vote will be used if more than 5 candiates volunteer. Otherwise the candidates will be selected automatically.

One member will be selected by other TC members as a TC secratary. The TC secratary is responsible for preparing a vote, and communicating the decision. The secretary also have a casting vote if the TC decision vote is a draw.

Any member can decide to drop out of being part of the TC. The TC can continue in reduced number unless their number goes below 3. If that happens, the new election needs to be scheduled within a month. If the number of member is 3 or more but the secretary is the member that dropped out, then s new secretary must be selected.

The RFC process will continue to be used for user facing changes. It will also continue to be used for all process changes. However, it will no longer be used for any technical decisions.

The TC members will only consider technical aspects. Specifically the decision is not made for the user facing changes which continue to be decided by the RFC process. The TC can however decide on the implementation of those features. In other words the TC can decide about implementation and ABI but not about API.

The TC does not need to follow technical decisions made by the RFC process in past. It means that if the RFC was used for a technical aspects like for example changing some internal structure, the TC would not be required to keep such internal structure unchanged. The TC should always make decision on case by case basis and not to be limited by previous decisions. However, it can and should consider those previous decisions.

The TC can decide whether the issue / pull request is a feature or a bug if there is a disagreement between RM and a core developer. If it is a feature, the TC can also decide whether it is a self contained feature by assessing its technical impact on php-src. This happens only on request like described in the work flow section.

The way how to discuss the issue is up to the TC members.

The vote happens between the TC members and can be private. Each member can either vote or abstain from the vote. The vote can take up to one week. It can finish earlier if all members vote or explicitly abstain from the vote. If the TC members do not vote or explicitly abstain from the vote during the voting week, they are automatically considered as if they explicitly abstain from the vote. If the result of the vote is draw, the secretary has got a casting vote.

The decision needs to be communicated publicly by commenting on GitHub issue or pull request that is being decided.

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-XX-XX and will end on 2023-XX-XX.

Links to external references, discussions or RFCs

Keep this updated with features that were discussed on the mail lists.