rfc:php_technical_committee
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
rfc:php_technical_committee [2023/03/06 17:03] – typo danack | rfc:php_technical_committee [2023/05/12 11:52] (current) – Close vote bukka | ||
---|---|---|---|
Line 1: | Line 1: | ||
====== PHP RFC: PHP Technical Committee ====== | ====== PHP RFC: PHP Technical Committee ====== | ||
- | * Version: | + | * Version: 1.0 |
* Date: 2023-03-03 | * Date: 2023-03-03 | ||
- | * Author: Jakub Zelenka, bukka@php.net | + | * Author: Jakub Zelenka |
- | * Status: | + | * Status: |
===== Introduction ===== | ===== Introduction ===== | ||
- | PHP uses voting system for deciding about changes | + | The Open Source project that develops the PHP language and its reference implementation |
- | It works well for that purpose but it is not that effective for deciding about purely technical changes that impact PHP | + | and vote on proposed |
- | internals and extension | + | not that effective for deciding about purely technical changes that impact PHP internals and extension |
- | contributors that sometimes happen. | + | clear how it should resolve |
===== Proposal ===== | ===== Proposal ===== | ||
- | This RFC proposes introduction of the PHP Technical Committee (TC) that would decide about all technical aspects of | + | This RFC proposes |
- | php-src. Specifically its main purpose is to decide about disagreements between | + | php-src |
- | that only. | + | |
==== Definitions ==== | ==== Definitions ==== | ||
Line 24: | Line 23: | ||
definitions: | 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:// | * php-src - Source code in https:// | ||
- | * PR - Pull request. | + | * core developer |
- | * process changes - Any changes impacting | + | * 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. | * pull request - php-src GitHub pull request. | ||
* RM - PHP release managers. | * RM - PHP release managers. | ||
- | * technical | + | |
- | * technical | + | |
- | * technical change - Any php-src change excluding user facing changes. It covers also the implementation of user facing changes. | + | * technical aspect - The portions of |
+ | * technical | ||
* TC - PHP Technical Committee. | * 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. | To further clarify some of the defined terms, following subsection provides some useful examples. | ||
Line 44: | Line 41: | ||
=== Changes === | === Changes === | ||
- | It is important to clarify difference between user facing change and technical changes. As it is defined the technical | + | 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 | 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. | + | still a technical change. |
- | interface | + | // |
For example if there is a proposal to add accessors for PHP classes, then everything that is visible to user space | 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 | like the constructs and their usage in PHP code is a user facing change. The actual C implementation and tests are | ||
a technical change. | a technical change. | ||
+ | |||
+ | ==== TC membership ==== | ||
+ | |||
+ | The TC consists of five elected members. | ||
+ | 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' | ||
+ | |||
+ | === Elections === | ||
+ | |||
+ | The election process takes place annually, concurrent with the election of the Release Managers in approximately | ||
+ | March/ | ||
+ | a call for nominations. | ||
+ | |||
+ | 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. | ||
+ | disqualification, | ||
+ | |||
+ | Once nominations are over, the voting process will begin. | ||
+ | |||
+ | 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. | ||
+ | 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' | ||
+ | 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. | ||
+ | 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 ==== | ==== Work flow ==== | ||
- | The work flow for TC is following: | + | The TC is primarily a reactive body, and is not expected to proactively search for issues. |
- | - Any core developer can add label tc-hold on issue or pull request. | + | Should a dispute |
- | - The core developer should mention | + | |
- | - 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 | + | |
- | - The TC announce its decision and reasoning by commenting | + | |
- | - The core developer will follow the decision which can mean (not limited | + | |
- | * merging the issue / PR | + | |
- | * closing / rejecting the issue / PR | + | |
- | * making requested change to the PR | + | |
- | It should | + | - Any core developer (including a TC member) may ask for TC resolution of an issue by adding the label '' |
- | problem and put label on it. | + | - An issue with the '' |
+ | - 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, | ||
+ | - 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 '' | ||
+ | - The decision of the TC is binding. | ||
+ | |||
+ | If an issue has been marked '' | ||
+ | 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. | ||
+ | |||
+ | The election of a new TC will "reset the clock" on any outstanding '' | ||
==== Decision process ==== | ==== Decision process ==== | ||
- | === RFC === | + | === User-facing changes |
- | The RFC process will continue to be used for user facing changes. | + | The RFC process will continue to be used for user facing changes. |
- | changes. | + | non-user-facing |
- | === TC === | + | TC members have no special role or authority in the RFC process. |
- | The TC members will only consider technical aspects. Specifically the decision is not made for the user facing | + | === Process |
- | 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 | + | The RFC process |
- | 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 | + | === Technical changes === |
- | 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 | + | As noted, |
- | to be communicated publicly by commenting on GitHub issue or pull request. | + | implementation of those features. In other words the TC can decide about implementation and C ABI and API but |
+ | not about PHP API. | ||
- | ==== TC membership ==== | + | 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 will be composed of 5 member who will be voted once a year together with release managers | + | The TC SHOULD give due consideration and weight to previous decisions regarding technical aspects, either |
- | It will be done using a single transferable vote if more than 5 candiates volunteer. The candidate must be a core | + | or by RFCs prior to the TC's creation. |
- | developer | + | sees best to ensure the quality |
- | If one of the members wants or needs to drop out of being part of the TC, the new volunteer will be selected using | + | Technical aspects on which the TC may make a decision include, but are not limited to: |
- | the RFC process. The vote happens only if there are more than one volunteer. The selection is automatic if there is | + | |
- | only one volunteer. | + | |
- | ===== Proposed Voting Choices ===== | + | * Whether a given pull request implements a feature or resolves a bug. |
+ | * Whether a given change qualifies as user-facing, | ||
+ | * Whether a given technical aspect or implementation approach is acceptable. | ||
- | As per the voting | + | === TC voting |
- | Voting started on 2023-XX-XX and will end on 2023-XX-XX. | + | Once an issue has been brought to the TC, the Secretary |
- | ===== References ===== | + | The vote will last for two weeks or until all TC members have voted, whichever comes first. |
+ | simple-majority, | ||
+ | as determined by the Secretary). | ||
+ | Abstentions do not count toward the result. | ||
- | Links to external references, discussions or RFCs | + | In case of a tie, the Secretary' |
+ | |||
+ | Alternatively, | ||
+ | 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. | ||
- | ===== Rejected Features ===== | + | Voting started on 2023-04-28 10:00 UTC and will end on 2023-05-12 10:00 UTC. |
- | Keep this updated with features that were discussed on the mail lists. | + | <doodle title=" |
+ | * Yes | ||
+ | * No | ||
+ | </ |
rfc/php_technical_committee.txt · Last modified: 2023/05/12 11:52 by bukka