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/16 15:45] – bukka | 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: |
* Date: 2023-03-03 | * Date: 2023-03-03 | ||
* Author: Jakub Zelenka (bukka@php.net), | * Author: Jakub Zelenka (bukka@php.net), | ||
- | * Status: | + | * Status: |
===== Introduction ===== | ===== Introduction ===== | ||
- | PHP uses its voting system | + | The Open Source project that develops the PHP language and its reference implementation uses an RFC process |
- | 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 |
Line 16: | Line 16: | ||
This RFC proposes an introduction of the PHP Technical Committee (TC) that would decide about all technical aspects of | This RFC proposes an introduction of the PHP Technical Committee (TC) that would decide about all technical aspects of | ||
- | php-src when there is a disagreements between core developers. | + | php-src when there are disagreements between core developers. |
==== Definitions ==== | ==== Definitions ==== | ||
Line 24: | Line 24: | ||
* php-src - Source code in https:// | * php-src - Source code in https:// | ||
- | * contributor - Anyone who has already contributed to php-src. | ||
* core developer - Anyone with write commit access to 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). | * 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 | + | * maintainer - person responsible for core subsystem (e.g. extension or SAPI) that is listed in the php-src |
* issue - php-src GitHub issue, including pull requests. | * issue - php-src GitHub issue, including pull requests. | ||
- | * process changes - Any changes impacting | + | * 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. | ||
Line 44: | Line 43: | ||
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 | ||
Line 66: | Line 65: | ||
The election process takes place annually, concurrent with the election of the Release Managers in approximately | The election process takes place annually, concurrent with the election of the Release Managers in approximately | ||
March/ | March/ | ||
- | a call for nominations. | + | a call for nominations. |
During that week, any eligible core developer may self-nominate by posting to the Internals mailing list. If the | 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 | + | candidate is paid to work on php-src or PHP extensions, they must state in their nomination which company or |
- | they work for. Failure to do so will result in disqualification, | + | organization |
+ | disqualification, | ||
Once nominations are over, the voting process will begin. | Once nominations are over, the voting process will begin. | ||
Line 86: | Line 86: | ||
Secretary, then the TC will elect a new Secretary from its number. | Secretary, then the TC will elect a new Secretary from its number. | ||
- | The TC may declare | + | 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 vote passes, the TC member is removed. | ||
Line 98: | Line 98: | ||
==== Work flow ==== | ==== Work flow ==== | ||
- | The TC is primarily a reactive body, and is not expected to proactively search for issues. However, TC members | + | The TC is primarily a reactive body, and is not expected to proactively search for issues. |
- | are permitted to comment on any open issue, and contributors are encouraged to give their comments appropriate weight. | + | |
Should a dispute or question about a change arise, the TC may be called on to resolve it. | 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-hold` to it and @-mentioning the TC GitHub team. | + | - Any core developer (including a TC member) may ask for TC resolution of an issue by adding the label '' |
- | - An issue with the `tc-hold` tag MUST NOT be merged. | + | - An issue with the '' |
- The TC members will confer in whatever manner they deem most convenient, public or private or both. | - 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 SHOULD consult with relevant other individuals, | ||
- The TC MUST deliver a decision within one month, via the mechanism described below. | - 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-hold` tag. | + | - 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. | - The decision of the TC is binding. | ||
- | If an issue has been marked | + | If an issue has been marked |
developer SHOULD post to the Internals mailing list a notification of absence. | 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 one month, then the entire TC | + | 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 |
- | is considered AWOL and removed. | + | |
- | The election of a new TC will "reset the clock" on any outstanding | + | The election of a new TC will "reset the clock" on any outstanding |
==== Decision process ==== | ==== Decision process ==== | ||
Line 140: | Line 138: | ||
The TC SHOULD NOT block the merging of a user-facing change approved by the RFC process, unless the provided | 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 | 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 TC finds more appropriate. | + | 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 | The TC SHOULD give due consideration and weight to previous decisions regarding technical aspects, either by the TC | ||
Line 154: | Line 152: | ||
=== TC voting === | === TC voting === | ||
- | Once an issue has been brought to the TC, the Secretary | + | Once an issue has been brought to the TC, the Secretary |
- | week. 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 one week or until all TC members have voted, whichever comes first. | + | The vote will last for two weeks or until all TC members have voted, whichever comes first. |
simple-majority, | simple-majority, | ||
as determined by the Secretary). | as determined by the Secretary). | ||
Line 173: | Line 169: | ||
As per the voting RFC a yes/no vote with a 2/3 majority is needed for this proposal to be accepted. | 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. | + | Voting started on 2023-04-28 10:00 UTC and will end on 2023-05-12 10:00 UTC. |
- | + | ||
- | ===== References ===== | + | |
- | + | ||
- | Links to external references, discussions or RFCs | + | |
- | + | ||
- | ===== Rejected Features ===== | + | |
- | + | ||
- | 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