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 11:07] – Larry's changes 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 |
- | * 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. Its primary but not only role is to resolve | + | php-src |
==== 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 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 |
- | | + | * pull request - php-src GitHub pull request. |
- | * pull request - php-src GitHub pull request | + | |
* RM - PHP release managers. | * RM - PHP release managers. | ||
- | * user facing changes - Changes in PHP language, user visible functions, classes, interfaces, constants and other user visible constructs. | + | * user facing changes - Changes in PHP language |
* 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 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 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. | ||
Line 45: | 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 59: | Line 57: | ||
The TC Secretary is responsible for: | The TC Secretary is responsible for: | ||
- | * Administering the election of the next set of TC members. | + | |
- | * Documenting and communicating any decisions of the TC. | + | * Documenting and communicating any decisions of the TC. |
- | * In case of a tie, the Secretary' | + | * In case of a tie, the Secretary' |
=== Elections === | === Elections === | ||
Line 67: | 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 87: | 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 99: | Line 98: | ||
==== Work flow ==== | ==== Work flow ==== | ||
- | The TC is primarily a reactive body, and is not expected to proactively search | + | 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 | + | - Any core developer (including a TC member) may ask for TC resolution of an issue by adding the label '' |
- | | + | - An issue with the '' |
- | - An issue with the `tc-hold` tag MUST NOT be merged. | + | |
- 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 133: | ||
As noted, the TC has no special role or authority on user-facing changes. | As noted, the TC has no special role or authority on user-facing changes. | ||
- | implementation of those features. In other words the TC can decide about implementation and ABI but not about API. | + | 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 | + | The TC SHOULD NOT block the merging of a user-facing change approved by the RFC process, unless the provided |
- | would result in introduction of new bugs, side effects not mentioned in the RFC, significant performance penalties, | + | implementation |
- | or if there is an equivalent implementation in progress that TC finds more appropriate. | + | penalties |
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 152: | Line 146: | ||
Technical aspects on which the TC may make a decision include, but are not limited to: | Technical aspects on which the TC may make a decision include, but are not limited to: | ||
- | * Whether a given PR is a feature or a bug. | + | |
- | * Whether a given change qualifies as user-facing, | + | * Whether a given change qualifies as user-facing, |
- | * Whether a given technical aspect or implementation approach is acceptable. | + | * Whether a given technical aspect or implementation approach is acceptable. |
=== 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 may be public or 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. |
- | with no quorum on a binary question (which could be yes/no or either/or, depending on the situation, as determined by | + | simple-majority, |
- | the Secretary). | + | as determined by the Secretary). |
- | do not count toward the result. | + | Abstentions do not count toward the result. |
In case of a tie, the Secretary' | In case of a tie, the Secretary' | ||
Line 177: | 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.1678964835.txt.gz · Last modified: 2023/03/16 11:07 by bukka