PHP RFC: PHP Technical Committee

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

PHP uses voting system for deciding about changes to PHP. This was created mainly for user visible changes in language. 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 exactly clear how it should resolve conflicts (on technical bases) between contributors that sometimes happen.

This RFC proposes 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 as defined 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 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. 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 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. TC can however decide on the implementation of those features. In other words 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 decide on case by case bases and not be limited by previous decisions. However, it can and should at least consider those previous decisions.

The TC can decide whether the issue / PR 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 and vote on the issue is up to the TC members. The only requirement is that the decision needs to be communicated publicly by commenting on GitHub issue or pull request.

The TC will be composed of 5 member who will be voted once a year together with release managers by the RFC process. It will be done using a single transferable vote if more than 5 candiates volunteer. The candidate must be a core developer and should have a general knowledge about PHP internals.

If one of the members wants or needs to drop out of being part of the TC, the new volunteer will be selected using the RFC process. The vote happens only if there are more than one volunteer. The selection is automatic if there is only one volunteer.

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.