rfc:php_technical_committee

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
rfc:php_technical_committee [2023/04/03 11:04] – bukkarfc: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: 0.4+  * Version: 1.0
   * Date: 2023-03-03   * Date: 2023-03-03
   * Author: Jakub Zelenka (bukka@php.net), Larry Garfield (larry@garfieldtech.com)   * Author: Jakub Zelenka (bukka@php.net), Larry Garfield (larry@garfieldtech.com)
-  * Status: Draft+  * Status: Declined
  
 ===== Introduction ===== ===== Introduction =====
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 26: Line 26:
   * 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 EXTENSION file or the php-src OWNERS files if added in the future.+  * 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.   * issue - php-src GitHub issue, including pull requests.
   * process changes - Any changes impacting how the PHP project is managed.   * process changes - Any changes impacting how the PHP project is managed.
Line 43: 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. Put another way, the _definition_ of the user interface is user facing only, while the +still a technical change. Put another way, the //definition// of the user interface is user facing only, while the 
-_implementation_ itself is a technical change.+//implementation// itself is a technical change.
  
 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 102: Line 102:
 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 ''tc-hold'' to it and @-mentioning the TC GitHub team. 
-  - An issue with the `tc-hold` tag MUST NOT be merged.+  - 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, including the core developers involved in the issue, Release Managers, and impacted maintainers as appropriate.     * The TC SHOULD consult with relevant other individuals, including the core developers involved in the issue, Release Managers, and impacted maintainers as appropriate.
   - 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 ''tc-hold'' tag.
   - The decision of the TC is binding.  That means a relevant change MUST NOT be merged until and unless it conforms with the TC's decision.  Depending on the decision, the core developer involved may merge the issue, close it, or revise it accordingly.   - The decision of the TC is binding.  That means a relevant change MUST NOT be merged until and unless it conforms with the TC's decision.  Depending on the decision, the core developer involved may merge the issue, close it, or revise it accordingly.
  
-If an issue has been marked `tc-hold` for more than two weeks with no response or acknowledgement from the TC, the+If an issue has been marked ''tc-hold'' for more than two weeks with no response or acknowledgement from the TC, the
 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 30 days, then the entire TC is automatically removed.  New elections must then be immediately called as described above. 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.  New elections must then be immediately called as described above.
  
-The election of a new TC will "reset the clock" on any outstanding `tc-hold` issues.+The election of a new TC will "reset the clock" on any outstanding ''tc-hold'' issues.
  
 ==== Decision process ==== ==== Decision process ====
Line 169: 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="Introduce the PHP Technical Committee as defined in this RFC" auth="bukka" voteType="single" closed="true">
 +   * Yes
 +   * No
 +</doodle>
rfc/php_technical_committee.1680519861.txt.gz · Last modified: 2023/04/03 11:04 by bukka

Page Tools