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/03/16 15:45] – 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.3+  * 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 =====
  
-PHP uses its voting system to decide about changes to PHP. This was created mainly for user facing changes. It works +The Open Source project that develops the PHP language and its reference implementation uses an RFC process to discuss 
-well for that purpose but it is not that effective for deciding about purely technical changes that impact PHP +and vote on proposed changes. This was created mainly for user facing changes. It works well for that purpose but it is 
-internals and extension API's. It is not clear how it should resolve conflicts on the technical basis between +not that effective for deciding about purely technical changes that impact PHP internals and extension APIs. It is not 
-contributors that sometimes happen.+clear how it should resolve technical conflicts between core developers.
  
  
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://github.com/php/php-src/.   * php-src - Source code in https://github.com/php/php-src/.
-  * 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 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 the way how PHP project is managed.+  * 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. The meaning of that is that the part of the user facing change that defines the user +still a technical change. Put another way, the //definition// of the user interface is user facing only, while the 
-interface is not 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 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/April.  (The exact date may vary year to year.)  The sitting TC Secretary officially begins the process with March/April.  (The exact date may vary year to year.)  The sitting TC Secretary officially begins the process with
-a call for nominations.  The nomination period lasts for one week.+a call for nominations.  The nomination period lasts for one month.
  
 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, as determined by the TC Secretary.+organization they work for to prevent potential conflicts of interest.  Failure to do so will result in 
 +disqualification, as determined by the TC Secretary.
  
 Once nominations are over, the voting process will begin.  Eligible voters are the same as for any RFC. Once nominations are over, the voting process will begin.  Eligible voters are the same as for any RFC.
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 one of its members AWOL after no communication from that individual for one month, by a majority vote.+Should a TC member become inactive for more than 30 days, the TC may declare that member's seat vacant, by a majority vote.
 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 ''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 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 removed.  New elections must then be immediately called as described above.
-is considered AWOL and 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 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 must allow all TC members time to offer their input within one +Once an issue has been brought to the TC, the Secretary will facilitate a discussion period lasting two weeks or until all TC members have had time to offer their input, whichever comes first.  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.
-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.  All votes are+The vote will last for two weeks or until all TC members have voted, whichever comes first.  All votes are
 simple-majority, with no quorum on a binary question (which could be yes/no or either/or, depending on the situation, simple-majority, with no quorum on a binary question (which could be yes/no or either/or, depending on the situation,
 as determined by the Secretary).  Members may explicitly abstain, and refraining from voting counts as an abstention. as determined by the Secretary).  Members may explicitly abstain, and refraining from voting counts as an abstention.
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="Introduce the PHP Technical Committee as defined in this RFC" auth="bukka" voteType="single" closed="true">
 +   * Yes
 +   * No
 +</doodle>
rfc/php_technical_committee.1678981543.txt.gz · Last modified: 2023/03/16 15:45 by bukka

Page Tools