Differences

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

--- rfc:php_technical_committee [2023/03/10 17:30] – bukka
+++ rfc:php_technical_committee [2023/05/12 11:52] (current) – Close vote bukka
@@ Line 1: / Line 1: @@
 ====== PHP RFC: PHP Technical Committee ======
-  * Version: 0.2
+  * Version: 1.0
   * Date: 2023-03-03
-  * Author: Jakub Zelenka, bukka@php.net
+  * Author: Jakub Zelenka (bukka@php.net), Larry Garfield (larry@garfieldtech.com)
-  * Status: Draft
+  * Status: Declined
 ===== 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
-php-src. Specifically its main purpose is to decide about disagreements between contributors but it is not limited to
+php-src when there are disagreements between core developers.
-that only.
 ==== Definitions ====
@@ Line 24: / Line 23: @@
 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 that is listed in php-src EXTENSION file.
   * php-src - Source code in https://github.com/php/php-src/.
-  * PR - Pull request.
+  * core developer - Anyone with write commit access to php-src.
-  * process changes - Any changes impacting the way how PHP project is managed and its bylaws.
+  * 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.
   * RM - PHP release managers.
-  * technical aspect - Technical change of any issue or pull request in php-src or commit to php-src master and dev branches.
+  * user facing changes - Changes in PHP language and its semantics, user visible functions, classes, interfaces, constants and other user visible constructs.
-  * technical descision - Decision on a technical aspect.
+  * 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 php-src change excluding user facing changes. It covers also the implementation of user facing 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.
+  * technical decision - Decision on a technical aspect.
   * 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.
@@ Line 44: / Line 41: @@
 === Changes ===
-It is important to clarify differnce 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
-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
@@ Line 53: / Line 50: @@
 a technical change.
-==== Work flow ====
+==== TC membership ====
-The work flow for TC is following:
+The TC consists of five elected members.  Any core developer is eligible to run for the TC.  One member of the TC,
+selected by the TC members themselves, is the TC Secretary.
-  - Any core developer can add label tc-hold on issue or pull request.
+The TC Secretary is responsible for:
-  - The core developer should mention the TC GitHub team to notify members of the TC.
-  - 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 on the issue or pull request
-  - The core developer will follow the decision which can mean (not limited to):
-    * merging the issue / PR
-    * closing / rejecting the issue / PR
-    * making requested change to the PR
-It should be noted that if the problem is with a specific commit, the core developer can create an issue specifying the
+  * Administering the election of the next set of TC members.
-problem and put label on it.
+  * Documenting and communicating any decisions of the TC.
+  * In case of a tie, the Secretary's vote will be considered the winning position.
-The TC decision should not take longer than month. If it takes longer than one month, the following work flow can be
+=== Elections ===
-applied:
-  - After a month of no response from the TC the core developer can send a formal notification to the internals mailing list.
-  - If the notification is ignored for more than one month by the TC, the core developer can send a formal warning to the internals mailing list.
-  - If the formal warning is also ignored for more than a month, then the core developer can call for new election of TC members
-  - New election happen within a month.
-There is a caveat that if the election happens due to yearly elections between any steps of the workflow above, the
+The election process takes place annually, concurrent with the election of the Release Managers in approximately
-core developer needs to send a new notification after the elections and starts the workflow again.
+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 month.
-==== TC membership ====
+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.  Failure to do so will result in
+disqualification, as determined by the TC Secretary.
-The TC candidates nominate themself to become a TC member. They must be a core developers and should have a general
+Once nominations are over, the voting process will begin.  Eligible voters are the same as for any RFC.
-knowledge about PHP internals. If the candidates are paid to work on php-src or PHP extensions, they must state in
-their nomination which company or organization they work for.
-The TC shoudl be composed of 5 members. If there are not enough candiates, it can be composed of reduced number of
+If there are five or fewer nominees, there is no vote and all nominated individuals are elected.
-members but it must have at least 3 members. The TC election of memebers will happen every year together with
-release managers selection. The RFC voting process using a single transferable vote will be used if more than 5
-candiates volunteer. Otherwise the candidates will be selected automatically.
-One member will be selected by other TC members as a TC secratary. The TC secratary is responsible for preparing a vote,
+If there are six or more nominees, a two week vote using the Single Transferable Vote method will take place.  The five
-and communicating the decision. The secretary also have a casting vote if the TC decision vote is a draw.
+winning candidates at the end of the vote are elected.
-Any member can decide to drop out of being part of the TC. The TC can continue in reduced number unless their number
+The newly elected TC members will elect from their own number a TC Secretary by simple majority.
-goes below 3. If that happens, the new election needs to be scheduled within a month. If the number of member is 3 or
-more but the secretary is the member that dropped out, then s new secretary must be selected.
+=== 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's seat vacant, by a majority vote.
+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.  The election process is the
+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 ====
+The TC is primarily a reactive body, and is not expected to proactively search for issues.
+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.
+  - 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 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 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.
+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.
+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.
 ==== Decision process ====
-=== RFC ===
+=== User-facing changes ===
-The RFC process will continue to be used for user facing changes. It will also continue to be used for all process
+The RFC process will continue to be used for user facing changes.  However, it will no longer be used for
-changes. However, it will no longer be used for any technical decisions.
+non-user-facing technical decisions.
-=== 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 changes
+=== Process changes ===
-which continue to be decided by the RFC process. The TC can however decide on the implementation of those features. In
-other words the 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 in past. It means that if the RFC was used
+The RFC process will continue to be used for process changes, including changes to the role of the TC.
-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 make decision on case by case basis and not to be limited by
-previous decisions. However, it can and should consider those previous decisions.
-The TC can decide whether the issue / pull request is a feature or a bug if there is a disagreement between RM and a
+=== Technical changes ===
-core 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 the issue is up to the TC members.
+As noted, the TC has no special role or authority on user-facing changes.  The TC may, however, decide on the
+implementation of those features. In other words the TC can decide about implementation and C ABI and API but
+not about PHP API.
-The vote happens between the TC members and can be private. Each member can either vote or abstain from the vote. The
+The TC SHOULD NOT block the merging of a user-facing change approved by the RFC process, unless the provided
-vote can take up to one week. It can finish earlier if all members vote or explicitly abstain from the vote. If the TC
+implementation would result in introduction of new bugs, side effects not mentioned in the RFC, significant performance
-members do not vote or explicitly abstain from the vote during the voting week, they are automatically considered as if
+penalties not mentioned in RFC, or if there is an equivalent implementation in progress that the TC finds more appropriate.
-they explicitly abstain from the vote. If the result of the vote is draw, the secretary has got a casting vote.
-The decision needs to be communicated publicly by commenting on GitHub issue or pull request that is being decided.
+The TC SHOULD give due consideration and weight to previous decisions regarding technical aspects, either by the TC
+or by RFCs prior to the TC's creation.  However, it is NOT REQUIRED to abide by them, and may make decisions as it
+sees best to ensure the quality and maintainability of the code at the time the decision is made.
+Technical aspects on which the TC may make a decision include, but are not limited to:
-===== Proposed Voting Choices =====
+  * Whether a given pull request implements a feature or resolves a bug.
+  * Whether a given change qualifies as user-facing, and thus requires an RFC.
+  * Whether a given technical aspect or implementation approach is acceptable.
-As per the voting RFC a yes/no vote with a 2/3 majority is needed for this proposal to be accepted.
+=== 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 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.
-===== References =====
+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,
+as determined by the Secretary).  Members may explicitly abstain, and refraining from voting counts as an abstention.
+Abstentions do not count toward the result.
-Links to external references, discussions or RFCs
+In case of a tie, the Secretary's vote will be considered the winning position.
+Alternatively, if there is clear consensus among the TC members the Secretary may opt to skip the vote and report the
+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="Introduce the PHP Technical Committee as defined in this RFC" auth="bukka" voteType="single" closed="true">
+   * Yes
+   * No
+</doodle>

Differences

Page Tools