From 2324865cbbc33ce9b9ced8f4b2f34794e5e12ce3 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Fri, 3 Mar 2023 15:08:55 +0000 Subject: [PATCH 01/38] Add initial PHP technical committee RFC --- rfc/php_technical_committee.wiki | 79 ++++++++++++++++++++++++++++++++ 1 file changed, 79 insertions(+) create mode 100644 rfc/php_technical_committee.wiki diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki new file mode 100644 index 0000000..65330be --- /dev/null +++ b/rfc/php_technical_committee.wiki @@ -0,0 +1,79 @@ +====== PHP RFC: PHP Technical Committee ====== + * Version: 0.1 + * Date: 2023-03-03 + * Author: Jakub Zelenka, bukka@php.net + * Status: Draft + +===== Introduction ===== + +PHP uses voting system for deciding about changes to PHP. This was created mainly for user visible changes in language. +It works well for that purpose but it is not that effective for deciding about purely technical changes that impact PHP +internals and extension API's. It is not exactly clear how it should resolve conflicts (on technical bases) between +contributors that sometimes happen. + + +===== Proposal ===== + +This RFC proposes 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 +that only. + +==== Definitions ==== + +The text contains various terms that need further clarification to prevent future wording dispute. Here are their +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) + * php-src - Source code in https://github.com/php/php-src/. + * RM - PHP release managers. + * technical aspect - Any issue or pull request in php-src or commit to php-src master and dev branches. + * TC - PHP Technical Committee. + * user facing feature - Feature resulting in change in PHP code (e.g. new language constructs, classes, functions and so on). + +==== Work flow ==== + +The work flow for TC is following: + + - Any core developer can add label tc-hold on issue or pull request. + - 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 if the problem impacting 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 specific commit, the core developer can create an issue specifying the +problem and put label on it. + +==== TC Decissions ==== + +The TC member will consider only technical aspects. Specifically the decission is not made on the user facing features +which will be still decided by the RFC process. TC can however decide on the implementation of those features. + +The TC can decide whether the issue / PR is a feature or a bug. If it is a feature it can also decide if it is a self +contained feature that can go to the lower branches. This happens only on request like described in the work flow. + +The way how to vote and discuss the issue is up to the TC members. + +==== TC membership ==== + +The TC will be composed of 5 member who will be voted once a year together with release managers by the RFC process. +The vote is not necessary if no more than 5 condidates volunteer. The candidate must be a core developer and should +have a general knowledge about PHP internals. + +===== Future Scope ===== +This section details areas where the feature might be improved in future, but that are not currently proposed in this RFC. + +===== Proposed Voting Choices ===== +Include these so readers know where you are heading and can discuss the proposed voting options. + +===== References ===== +Links to external references, discussions or RFCs + +===== Rejected Features ===== +Keep this updated with features that were discussed on the mail lists. \ No newline at end of file From a57dcf1def56e2605fc5c24271c48bc5e7a1f008 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Fri, 3 Mar 2023 20:07:40 +0000 Subject: [PATCH 02/38] Update rfc/php_technical_committee.wiki Co-authored-by: George Peter Banyard --- rfc/php_technical_committee.wiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 65330be..5aacfd4 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -52,8 +52,8 @@ problem and put label on it. ==== TC Decissions ==== -The TC member will consider only technical aspects. Specifically the decission is not made on the user facing features -which will be still decided by the RFC process. TC can however decide on the implementation of those features. +The TC members will only consider technical aspects. Specifically the decision is not made for user facing features +which continue to be decided by the RFC process. TC can however decide on the implementation of those features. The TC can decide whether the issue / PR is a feature or a bug. If it is a feature it can also decide if it is a self contained feature that can go to the lower branches. This happens only on request like described in the work flow. From 4b1c8de37932a77422690bc2588afefc66fc216a Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Fri, 3 Mar 2023 20:07:52 +0000 Subject: [PATCH 03/38] Update rfc/php_technical_committee.wiki Co-authored-by: George Peter Banyard --- rfc/php_technical_committee.wiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 5aacfd4..c6c7199 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -47,7 +47,7 @@ The work flow for TC is following: * closing / rejecting the issue / PR * making requested change to the PR -It should be noted that if the problem is with specific commit, the core developer can create an issue specifying the +It should be noted that if the problem is with a specific commit, the core developer can create an issue specifying the problem and put label on it. ==== TC Decissions ==== From 3307cad142ae9f949b6b115c44afbd32f8422033 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Fri, 3 Mar 2023 20:20:09 +0000 Subject: [PATCH 04/38] Reword and update some parts --- rfc/php_technical_committee.wiki | 16 ++++++++++------ 1 file changed, 10 insertions(+), 6 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index c6c7199..ccb9283 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -39,7 +39,7 @@ The work flow for TC is following: - Any core developer can add label tc-hold on issue or pull request. - 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 if the problem impacting code maintained by the maintainer + * 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): @@ -50,21 +50,25 @@ The work flow for TC is following: It should be noted that if the problem is with a specific commit, the core developer can create an issue specifying the problem and put label on it. -==== TC Decissions ==== +==== TC Decisions ==== The TC members will only consider technical aspects. Specifically the decision is not made for user facing features which continue to be decided by the RFC process. TC can however decide on the implementation of those features. -The TC can decide whether the issue / PR is a feature or a bug. If it is a feature it can also decide if it is a self -contained feature that can go to the lower branches. This happens only on request like described in the work flow. +The TC can decide whether the issue / PR is a feature or a bug if there is a disagreement between RM and a core +developer. If it is a feature it can also decide if it is a self contained feature by assessing its technical +impact. This happens only on request like described in the work flow. The way how to vote and discuss the issue is up to the TC members. ==== TC membership ==== The TC will be composed of 5 member who will be voted once a year together with release managers by the RFC process. -The vote is not necessary if no more than 5 condidates volunteer. The candidate must be a core developer and should -have a general knowledge about PHP internals. +It will be done using a single transferable vote if more than 5 candiates volunteer. The candidate must be a core +developer and should have a general knowledge about PHP internals. + +If one of the members wants or needs to drop out of being part of the TC, the new volunteer is selected using the RFC +process if there are more volunteer. The selection is automatic if there is only one volunteer. ===== Future Scope ===== This section details areas where the feature might be improved in future, but that are not currently proposed in this RFC. From 6b992c138a564ab944ccc4adb3b9149f15f6ceb8 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Sun, 5 Mar 2023 15:27:55 +0000 Subject: [PATCH 05/38] Update TC proposal --- rfc/php_technical_committee.wiki | 35 ++++++++++++++++++++++++-------- 1 file changed, 26 insertions(+), 9 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index ccb9283..54715d7 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -26,11 +26,17 @@ 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. * php-src - Source code in https://github.com/php/php-src/. + * PR - Pull request. + * processing changes - Any changes impacting the way how PHP project is managed and its bylaws. + * pull request - php-src GitHub pull request. * RM - PHP release managers. - * technical aspect - Any issue or pull request in php-src or commit to php-src master and dev branches. + * technical aspect - Technical side of any issue or pull request in php-src or commit to php-src master and dev branches. + * technical descision - Decision on a technical aspect. + * technical side - All php-src changes excluding user facing changes. It covers alse the implementation of user facing changes. * TC - PHP Technical Committee. - * user facing feature - Feature resulting in change in PHP code (e.g. new language constructs, classes, functions and so on). + * user facing changes - Changes in PHP languege, user visible funtions, classes, interfaces, constants and other user visible constructs. ==== Work flow ==== @@ -50,16 +56,26 @@ The work flow for TC is following: It should be noted that if the problem is with a specific commit, the core developer can create an issue specifying the problem and put label on it. -==== TC Decisions ==== +==== Decision process ==== -The TC members will only consider technical aspects. Specifically the decision is not made for user facing features +=== RFC === + +The RFC process will continue to be used for user facing changes. It will also continue to be used for all processing +changes. However, it will no longer be used for any technical decisions. + +=== TC === + +The TC members will only consider technical aspects. Specifically the decision is not made for the user facing changes which continue to be decided by the RFC process. TC can however decide on the implementation of those features. +The TC does not need to follow technical decisions made previously by the RFC process. + The TC can decide whether the issue / PR is a feature or a bug if there is a disagreement between RM and a core -developer. If it is a feature it can also decide if it is a self contained feature by assessing its technical -impact. This happens only on request like described in the work flow. +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 vote and discuss the issue is up to the TC members. +The way how to discuss and vote on the issue is up to the TC members. The only requirement is that the decision needs +to be communicated publicly by commenting on GitHub issue or pull request. ==== TC membership ==== @@ -67,8 +83,9 @@ The TC will be composed of 5 member who will be voted once a year together with It will be done using a single transferable vote if more than 5 candiates volunteer. The candidate must be a core developer and should have a general knowledge about PHP internals. -If one of the members wants or needs to drop out of being part of the TC, the new volunteer is selected using the RFC -process if there are more volunteer. The selection is automatic if there is only one volunteer. +If one of the members wants or needs to drop out of being part of the TC, the new volunteer will be selected using +the RFC process. The vote happens only if there are more than one volunteer. The selection is automatic if there is +only one volunteer. ===== Future Scope ===== This section details areas where the feature might be improved in future, but that are not currently proposed in this RFC. From 561a326ef83c291b3481da9d81d1e7257825326f Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Sun, 5 Mar 2023 15:31:46 +0000 Subject: [PATCH 06/38] Update other sections in TC RFC --- rfc/php_technical_committee.wiki | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 54715d7..5dfc41a 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -87,14 +87,16 @@ If one of the members wants or needs to drop out of being part of the TC, the ne the RFC process. The vote happens only if there are more than one volunteer. The selection is automatic if there is only one volunteer. -===== Future Scope ===== -This section details areas where the feature might be improved in future, but that are not currently proposed in this RFC. - ===== Proposed Voting Choices ===== -Include these so readers know where you are heading and can discuss the proposed voting options. + +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. ===== References ===== + Links to external references, discussions or RFCs ===== Rejected Features ===== + Keep this updated with features that were discussed on the mail lists. \ No newline at end of file From 067411659385573c4b3e07068b8240efa4e6cc03 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Sun, 5 Mar 2023 19:44:02 +0000 Subject: [PATCH 07/38] Update some wording - feedback to Larry --- rfc/php_technical_committee.wiki | 30 ++++++++++++++++++++++++------ 1 file changed, 24 insertions(+), 6 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 5dfc41a..e2003ed 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -27,17 +27,31 @@ definitions: * 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 as defined in php-src EXTENSION file * php-src - Source code in https://github.com/php/php-src/. * PR - Pull request. - * processing changes - Any changes impacting the way how PHP project is managed and its bylaws. + * process changes - Any changes impacting the way how PHP project is managed and its bylaws. * pull request - php-src GitHub pull request. * RM - PHP release managers. - * technical aspect - Technical side of any issue or pull request in php-src or commit to php-src master and dev branches. + * technical aspect - Technical change of any issue or pull request in php-src or commit to php-src master and dev branches. * technical descision - Decision on a technical aspect. - * technical side - All php-src changes excluding user facing changes. It covers alse the implementation of user facing changes. + * technical change - Any php-src change excluding user facing changes. It covers also the implementation of user facing changes. * 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. + +=== Changes === + +It is important to clarify differnce 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 +interface is not a technical change. + +For example if there is a proposal to add accessors for PHP classes, then everything that is visible to user space +like the constructs and their usage in PHP code is a user facing change. The actual C implementation and tests are +a technical change. + ==== Work flow ==== The work flow for TC is following: @@ -60,15 +74,19 @@ problem and put label on it. === RFC === -The RFC process will continue to be used for user facing changes. It will also continue to be used for all processing +The RFC process will continue to be used for user facing changes. It will also continue to be used for all process changes. However, it will no longer be used for any technical decisions. === TC === The TC members will only consider technical aspects. Specifically the decision is not made for the user facing changes -which continue to be decided by the RFC process. TC can however decide on the implementation of those features. +which continue to be decided by the RFC process. TC can however decide on the implementation of those features. In +other words TC can decide about implementation and ABI but not about API. -The TC does not need to follow technical decisions made previously by the RFC process. +The TC does not need to follow technical decisions made by the RFC process in past. It means that if the RFC was used +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 decide on case by case bases and not be limited by previous +decisions. However, it can and should at least consider those previous decisions. The TC can decide whether the issue / PR is a feature or a bug if there is a disagreement between RM and a core developer. If it is a feature, the TC can also decide whether it is a self contained feature by assessing its technical From df81d62312f2a66f6216f15468ccbe5cc48d89ae Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Wed, 8 Mar 2023 15:41:58 +0000 Subject: [PATCH 08/38] Extend the TC RFC --- rfc/php_technical_committee.wiki | 34 +++++++++++++++++++++++--------- 1 file changed, 25 insertions(+), 9 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index e2003ed..1d825cc 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -70,6 +70,25 @@ The work flow for TC is following: It should be noted that if the problem is with a specific commit, the core developer can create an issue specifying the problem and put label on it. +The TC decision should not take longer than month. If it takes longer than one month, the core developer can send a +formal notification to the internals mailing list. If this is ignored for more than one month by the TC, the core +developer can send a formal warning to the internals mailing list. If this is also ignored for more than a month, +then the core developer can call for new election of TC members that needs to happen within a month. If the election +happens due to yearly elections, the core developer needs to send a new notification after the elections. + +==== TC membership ==== + +The TC will be composed of 5 member who will be voted once a year together with release managers by the RFC process. +It will be done using a single transferable vote if more than 5 candiates volunteer. The candidate must be a core +developer and should have a general knowledge about PHP internals. If the candidates are paid to work on PHP, they +need to state which company or organization they represent. + +One member will be selected by other members as a TC secratary. The TC secratary is responsible for preparing a vote +and communicating the decision. + +Any member can decide to drop out of being part of the TC. The TC can continue in reduced number unless their number +goes below 3. If that happens, the new election needs to be scheduled within a month. + ==== Decision process ==== === RFC === @@ -92,18 +111,15 @@ The TC can decide whether the issue / PR is a feature or a bug if there is a dis 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 and vote on the issue is up to the TC members. The only requirement is that the decision needs -to be communicated publicly by commenting on GitHub issue or pull request. +The way how to discuss the issue is up to the TC members. -==== TC membership ==== +The vote happens between the TC members and can be private. Each member can either vote or abstain from the vote. The +vote can take up to one week. It can finish earlier if all members vote or explicitly abstain from the vote. If the TC +members do not vote or explicitly abstain from the vote during the voting week, they are automatically considered as +abstaining from the vote. If the result of the vote is draw, the secretary can select the wining option. -The TC will be composed of 5 member who will be voted once a year together with release managers by the RFC process. -It will be done using a single transferable vote if more than 5 candiates volunteer. The candidate must be a core -developer and should have a general knowledge about PHP internals. +The decision needs to be communicated publicly by commenting on GitHub issue or pull request that is being decided. -If one of the members wants or needs to drop out of being part of the TC, the new volunteer will be selected using -the RFC process. The vote happens only if there are more than one volunteer. The selection is automatic if there is -only one volunteer. ===== Proposed Voting Choices ===== From 7e98febf49e4fd6762963aaf855a379b68fc4abc Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Fri, 10 Mar 2023 17:29:37 +0000 Subject: [PATCH 09/38] TC RFC: Improve wording and clarify some cases better --- rfc/php_technical_committee.wiki | 67 ++++++++++++++++++-------------- 1 file changed, 38 insertions(+), 29 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 1d825cc..53fdf57 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -1,20 +1,20 @@ ====== PHP RFC: PHP Technical Committee ====== - * Version: 0.1 + * Version: 0.2 * Date: 2023-03-03 * Author: Jakub Zelenka, bukka@php.net * Status: Draft ===== Introduction ===== -PHP uses voting system for deciding about changes to PHP. This was created mainly for user visible changes in language. -It works well for that purpose but it is not that effective for deciding about purely technical changes that impact PHP -internals and extension API's. It is not exactly clear how it should resolve conflicts (on technical bases) between +PHP uses its voting system to decide about changes to PHP. This was created mainly for user facing changes. It works +well for that purpose but it is not that effective for deciding about purely technical changes that impact PHP +internals and extension API's. It is not clear how it should resolve conflicts on the technical basis between contributors that sometimes happen. ===== Proposal ===== -This RFC proposes 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. Specifically its main purpose is to decide about disagreements between contributors but it is not limited to that only. @@ -25,9 +25,9 @@ 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) + * 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 as defined in php-src EXTENSION file + * 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. * process changes - Any changes impacting the way how PHP project is managed and its bylaws. @@ -43,7 +43,7 @@ To further clarify some of the defined terms, following subsection provides some === 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 differnce 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 interface is not a technical change. @@ -70,24 +70,33 @@ The work flow for TC is following: It should be noted that if the problem is with a specific commit, the core developer can create an issue specifying the problem and put label on it. -The TC decision should not take longer than month. If it takes longer than one month, the core developer can send a -formal notification to the internals mailing list. If this is ignored for more than one month by the TC, the core -developer can send a formal warning to the internals mailing list. If this is also ignored for more than a month, -then the core developer can call for new election of TC members that needs to happen within a month. If the election -happens due to yearly elections, the core developer needs to send a new notification after the elections. +The TC decision should not take longer than month. If it takes longer than one month, the following work flow can be +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 +core developer needs to send a new notification after the elections and starts the workflow again. ==== TC membership ==== -The TC will be composed of 5 member who will be voted once a year together with release managers by the RFC process. -It will be done using a single transferable vote if more than 5 candiates volunteer. The candidate must be a core -developer and should have a general knowledge about PHP internals. If the candidates are paid to work on PHP, they -need to state which company or organization they represent. +The TC candidates nominate themself to become a TC member. They must be a core developers and should have a general +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 +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 members as a TC secratary. The TC secratary is responsible for preparing a vote -and communicating the decision. +One member will be selected by other TC members as a TC secratary. The TC secratary is responsible for preparing a vote, +and communicating the decision. The secretary also have a casting vote if the TC decision vote is a draw. Any member can decide to drop out of being part of the TC. The TC can continue in reduced number unless their number -goes below 3. If that happens, the new election needs to be scheduled within a month. +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. ==== Decision process ==== @@ -99,24 +108,24 @@ changes. However, it will no longer be used for any technical decisions. === TC === The TC members will only consider technical aspects. Specifically the decision is not made for the user facing changes -which continue to be decided by the RFC process. TC can however decide on the implementation of those features. In -other words TC can decide about implementation and ABI but not about API. +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 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 decide on case by case bases and not be limited by previous -decisions. However, it can and should at least consider those previous decisions. +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 / PR is a feature or a bug if there is a disagreement between RM and a 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 TC can decide whether the issue / pull request is a feature or a bug if there is a disagreement between RM and a +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. The vote happens between the TC members and can be private. Each member can either vote or abstain from the vote. The vote can take up to one week. It can finish earlier if all members vote or explicitly abstain from the vote. If the TC -members do not vote or explicitly abstain from the vote during the voting week, they are automatically considered as -abstaining from the vote. If the result of the vote is draw, the secretary can select the wining option. +members do not vote or explicitly abstain from the vote during the voting week, they are automatically considered as if +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. From 2ea814ec57874df81d53c94af9885ca7287b2dc0 Mon Sep 17 00:00:00 2001 From: Larry Garfield Date: Tue, 14 Mar 2023 19:41:15 -0500 Subject: [PATCH 10/38] Spelling fixes. --- rfc/php_technical_committee.wiki | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 53fdf57..2eb2bec 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -34,16 +34,16 @@ definitions: * 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. - * technical descision - Decision on a technical aspect. + * technical decision - Decision on a technical aspect. * technical change - Any php-src change excluding user facing changes. It covers also the implementation of user facing changes. * TC - PHP Technical Committee. - * user facing changes - Changes in PHP languege, user visible funtions, classes, interfaces, constants and other user visible constructs. + * user facing changes - Changes in PHP language, user visible functions, classes, interfaces, constants and other user visible constructs. To further clarify some of the defined terms, following subsection provides some useful examples. === 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 interface is not a technical change. @@ -86,12 +86,12 @@ The TC candidates nominate themself to become a TC member. They must be a core d 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 -members but it must have at least 3 members. The TC election of memebers will happen every year together with +The TC shoudl be composed of 5 members. If there are not enough candidates, it can be composed of reduced number of +members but it must have at least 3 members. The TC election of members 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, +One member will be selected by other TC members as a TC secretary. The TC secretary is responsible for preparing a vote, and communicating the decision. The secretary also have a casting vote if the TC decision vote is a draw. Any member can decide to drop out of being part of the TC. The TC can continue in reduced number unless their number @@ -142,4 +142,4 @@ Links to external references, discussions or RFCs ===== Rejected Features ===== -Keep this updated with features that were discussed on the mail lists. \ No newline at end of file +Keep this updated with features that were discussed on the mail lists. From 6489ca9e5e8145f69fefd05a266e7ba26aaa1d3a Mon Sep 17 00:00:00 2001 From: Larry Garfield Date: Tue, 14 Mar 2023 21:15:30 -0500 Subject: [PATCH 11/38] Revise wording and flow of the proposal. --- rfc/php_technical_committee.wiki | 168 +++++++++++++++++++------------ 1 file changed, 103 insertions(+), 65 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 2eb2bec..8a8ae6a 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -15,29 +15,28 @@ contributors that sometimes happen. ===== Proposal ===== 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 -that only. +php-src. Its primary but not only role is to resolve disagreements between contributors. ==== Definitions ==== The text contains various terms that need further clarification to prevent future wording dispute. Here are their definitions: + * 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 right 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). + * maintainer - person responsible for extension or SAPI that is listed in the php-src EXTENSION file. * 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. + * PR - Pull request * process changes - Any changes impacting the way how PHP project is managed and its bylaws. - * pull request - php-src GitHub pull request. + * pull request - php-src GitHub pull request or issue. * 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, user visible functions, classes, interfaces, constants and other user visible constructs. + * 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 decision - Decision on a technical aspect. - * technical change - Any php-src change excluding user facing changes. It covers also the implementation of user facing changes. * TC - PHP Technical Committee. - * user facing changes - Changes in PHP language, user visible functions, classes, interfaces, constants and other user visible constructs. To further clarify some of the defined terms, following subsection provides some useful examples. @@ -52,83 +51,122 @@ For example if there is a proposal to add accessors for PHP classes, then everyt like the constructs and their usage in PHP code is a user facing change. The actual C implementation and tests are 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 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 +The TC Secretary is responsible for: -It should be noted that if the problem is with a specific commit, the core developer can create an issue specifying the -problem and put label on it. +* Administering the election of the next set of TC members. +* 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 -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. +=== Elections === -There is a caveat that if the election happens due to yearly elections between any steps of the workflow above, the -core developer needs to send a new notification after the elections and starts the workflow again. +The election process takes place annually, concurrent with the election of a release manager in approximately +March/April. (The exact date may vary year to hear.) The sitting TC Secretary officially begins the process with +a call for nominations. The nomination period lasts for one week. -==== 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. 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. + +If there are five or fewer nominees, there is no vote and all nominated individuals are elected. + +If there are six or more nominees, a two week vote using the Single Transferable Vote method will take place. The five +winning candidates at the end of the vote are elected. + +The newly elected TC members will elect from their own number a TC Secretary by simple majority. + +=== Vacancies === -The TC candidates nominate themself to become a TC member. They must be a core developers and should have a general -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. +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. -The TC shoudl be composed of 5 members. If there are not enough candidates, it can be composed of reduced number of -members but it must have at least 3 members. The TC election of members 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. +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. -One member will be selected by other TC members as a TC secretary. The TC secretary is responsible for preparing a vote, -and communicating the decision. The secretary also have a casting vote if the TC decision vote is a draw. +==== Work flow ==== + +The TC is primarily a reactive body, and is not expected to proactively search PRs for issues. However, TC members +are permitted to comment on any open PR, and core developers 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. + + - Any developer (including a TC member) may ask for TC resolution of a PR 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 PR, Release + Managers, and impacted extension 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 or PR in a comment on the issue and + removing 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 one month, then the entire TC +is considered AWOL. The senior-most Release Manager of the current stable release will step in to act as TC Secretary +and immediately call for a new vacancy election as described above. -Any member can decide to drop out of being part of the TC. The TC can continue in reduced number unless their number -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. +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. However, it will no longer be used for +non-user-facing technical decisions. + +TC members have no special role or authority in the RFC process. + +=== Process changes === + +The RFC process will continue to be used for process changes, including changes to the role of the TC. + +=== Technical changes === + +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 ABI but not about API. -The RFC process will continue to be used for user facing changes. It will also continue to be used for all process -changes. However, it will no longer be used for any technical decisions. +The TC SHOULD NOT block the merging of a user-facing change approved by the RFC process, unless the provided implementation +would result in security issues or significant performance penalties. If so, TC members are expected to actively participate +in finding a more acceptable alternative. -=== TC === +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. -The TC members will only consider technical aspects. Specifically the decision is not made for the user facing 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. +Technical aspects on which the TC may make a decision include, but are not limited to: -The TC does not need to follow technical decisions made by the RFC process in past. It means that if the RFC was used -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. +* Whether a given PR is a feature or 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. -The TC can decide whether the issue / pull request is a feature or a bug if there is a disagreement between RM and a -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. +=== TC voting === -The way how to discuss the issue is up to the TC members. +Once an issue has been brought to the TC, the Secretary must allow all TC members time to offer their input within one +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 happens between the TC members and can be private. Each member can either vote or abstain from the vote. The -vote can take up to one week. It can finish earlier if all members vote or explicitly abstain from the vote. If the TC -members do not vote or explicitly abstain from the vote during the voting week, they are automatically considered as if -they explicitly abstain from the vote. If the result of the vote is draw, the secretary has got a casting vote. +The vote will last for one week 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. -The decision needs to be communicated publicly by commenting on GitHub issue or pull request that is being decided. +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 ===== From 743f490393b1e17593cf5fa9e5b3030f8caccd03 Mon Sep 17 00:00:00 2001 From: Larry Garfield Date: Tue, 14 Mar 2023 21:16:48 -0500 Subject: [PATCH 12/38] Define issues to include PRs, as that makes it easier to refer to both of them. Also, GitHub does, too. --- rfc/php_technical_committee.wiki | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 8a8ae6a..3b9cc9e 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -27,7 +27,7 @@ definitions: * 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). * maintainer - person responsible for extension or SAPI that is listed in the php-src EXTENSION file. - * issue - php-src GitHub issue. + * issue - php-src GitHub issue, including pull requests. * PR - Pull request * process changes - Any changes impacting the way how PHP project is managed and its bylaws. * pull request - php-src GitHub pull request or issue. @@ -93,18 +93,18 @@ same as for any other election, but the newly elected TC members will serve only ==== Work flow ==== The TC is primarily a reactive body, and is not expected to proactively search PRs for issues. However, TC members -are permitted to comment on any open PR, and core developers are encouraged to give their comments appropriate weight. +are permitted to comment on any open issue, and core developers 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. - - Any developer (including a TC member) may ask for TC resolution of a PR by adding the label `tc-hold` to it and + - Any developer (including a TC member) may ask for TC resolution of a 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 PR, Release + * The TC SHOULD consult with relevant other individuals, including the core developers involved in the issue, Release Managers, and impacted extension 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 or PR in a comment on the issue and + - The TC Secretary MUST announce the decision and reasoning for it on the issue or issue in a comment on the issue and removing 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 From 3c3c321a7ba711d78973ee9c41bd231004a1a7c5 Mon Sep 17 00:00:00 2001 From: Larry Garfield Date: Tue, 14 Mar 2023 21:20:40 -0500 Subject: [PATCH 13/38] Wording fixes. --- rfc/php_technical_committee.wiki | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 3b9cc9e..f094287 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -93,7 +93,7 @@ same as for any other election, but the newly elected TC members will serve only ==== Work flow ==== The TC is primarily a reactive body, and is not expected to proactively search PRs for issues. However, TC members -are permitted to comment on any open issue, and core developers are encouraged to give their comments appropriate weight. +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. @@ -104,8 +104,7 @@ Should a dispute or question about a change arise, the TC may be called on to re * The TC SHOULD consult with relevant other individuals, including the core developers involved in the issue, Release Managers, and impacted extension 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 or issue in a comment on the issue and - removing 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. From 14e5b02fd196ba367e8f5224afd452f186fe0cf3 Mon Sep 17 00:00:00 2001 From: Larry Garfield Date: Wed, 15 Mar 2023 14:35:45 -0500 Subject: [PATCH 14/38] Minor tweaks and spelling fixes from Jakub Co-authored-by: Jakub Zelenka --- rfc/php_technical_committee.wiki | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index f094287..828714d 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -65,7 +65,7 @@ The TC Secretary is responsible for: === Elections === The election process takes place annually, concurrent with the election of a release manager in approximately -March/April. (The exact date may vary year to hear.) 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. During that week, any eligible core developer may self-nominate by posting to the Internals mailing list. If the @@ -97,7 +97,7 @@ are permitted to comment on any open issue, and contributors are encouraged to g Should a dispute or question about a change arise, the TC may be called on to resolve it. - - Any developer (including a TC member) may ask for TC resolution of a 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 `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. @@ -113,7 +113,7 @@ If an issue has been marked `tc-hold` for more than two weeks with no response o 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 -is considered AWOL. The senior-most Release Manager of the current stable release will step in to act as TC Secretary +is considered AWOL. 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 as described above. The election of a new TC will "reset the clock" on any outstanding `tc-hold` issues. From bf2af666365fe94ccd3615acef8a40aeaa3f9b2d Mon Sep 17 00:00:00 2001 From: Larry Garfield Date: Wed, 15 Mar 2023 17:19:33 -0500 Subject: [PATCH 15/38] Refine caveats on the TC slightly. --- rfc/php_technical_committee.wiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 828714d..3aae605 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -137,8 +137,8 @@ As noted, the TC has no special role or authority on user-facing changes. The T implementation of those features. In other words the TC can decide about implementation and ABI but not about API. The TC SHOULD NOT block the merging of a user-facing change approved by the RFC process, unless the provided implementation -would result in security issues or significant performance penalties. If so, TC members are expected to actively participate -in finding a more acceptable alternative. +would result in introduction of new bugs, side effects not mentioned in the RFC, significant performance penalties, + or if there is an equivalent implementation in progress that TC finds more appropriate. 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 From d63aa3c0af570f31787452882c73345f0b660004 Mon Sep 17 00:00:00 2001 From: Larry Garfield Date: Wed, 15 Mar 2023 17:25:16 -0500 Subject: [PATCH 16/38] Combine RM-as-election-manager clause back into the elections part, for clarity. --- rfc/php_technical_committee.wiki | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 3aae605..1722bbc 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -64,7 +64,7 @@ The TC Secretary is responsible for: === Elections === -The election process takes place annually, concurrent with the election of a release manager 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 a call for nominations. The nomination period lasts for one week. @@ -86,10 +86,16 @@ The newly elected TC members will elect from their own number a TC Secretary by 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. +The TC may declare one of its members AWOL after no communication from that individual for one month, 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 PRs for issues. However, TC members @@ -113,8 +119,7 @@ If an issue has been marked `tc-hold` for more than two weeks with no response o 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 -is considered AWOL. 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 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. From 862ad5f97979d4ff68a85e56880c1663524e438b Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Thu, 16 Mar 2023 11:13:23 +0000 Subject: [PATCH 17/38] Fix some wiki formatting issues --- rfc/php_technical_committee.wiki | 37 +++++++++++++++----------------- 1 file changed, 17 insertions(+), 20 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 1722bbc..e3ed40a 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -58,9 +58,9 @@ selected by the TC members themselves, is the TC Secretary. The TC Secretary is responsible for: -* Administering the election of the next set of TC members. -* Documenting and communicating any decisions of the TC. -* In case of a tie, the Secretary's vote will be considered the winning position. + * Administering the election of the next set of TC members. + * Documenting and communicating any decisions of the TC. + * In case of a tie, the Secretary's vote will be considered the winning position. === Elections === @@ -103,17 +103,14 @@ are permitted to comment on any open issue, and contributors are encouraged to g 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. - 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 extension 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. + - 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. @@ -141,9 +138,9 @@ The RFC process will continue to be used for process changes, including changes 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 ABI but not about API. -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 penalties, - or if there is an equivalent implementation in progress that TC finds more appropriate. +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 +penalties, or if there is an equivalent implementation in progress that TC finds more appropriate. 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 @@ -151,20 +148,20 @@ sees best to ensure the quality and maintainability of the code at the time the 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, and thus requires an RFC. -* Whether a given technical aspect or implementation approach is acceptable. + * Whether a given PR is a feature or 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. === 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 -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. +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. 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. +The vote will last for one week 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. In case of a tie, the Secretary's vote will be considered the winning position. From 6c7b290f9a0ae14fbfb91fe708a2ea6e8d97b642 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Thu, 16 Mar 2023 12:46:17 +0000 Subject: [PATCH 18/38] Update rfc/php_technical_committee.wiki Co-authored-by: Ilija Tovilo --- rfc/php_technical_committee.wiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index e3ed40a..7578a85 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -148,7 +148,7 @@ sees best to ensure the quality and maintainability of the code at the time the 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 PR 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. From 03f5be014a0de98899fe3becbcd0f444ca02e34a Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Thu, 16 Mar 2023 13:14:37 +0000 Subject: [PATCH 19/38] Fix TC feedback --- rfc/php_technical_committee.wiki | 23 +++++++++++------------ 1 file changed, 11 insertions(+), 12 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 7578a85..9882329 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -15,7 +15,7 @@ contributors that sometimes happen. ===== Proposal ===== 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 disagreements between contributors. +php-src when there is a disagreements between core developers. ==== Definitions ==== @@ -26,13 +26,12 @@ definitions: * contributor - Anyone who has already contributed 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). - * maintainer - person responsible for extension or SAPI that is listed in the php-src EXTENSION file. + * maintainer - person responsible for extension or SAPI that is listed in the php-src EXTENSION file or the php-src OWNERS file if added in the future. * issue - php-src GitHub issue, including pull requests. - * PR - Pull request * process changes - Any changes impacting the way how PHP project is managed and its bylaws. - * pull request - php-src GitHub pull request or issue. + * pull request - php-src GitHub pull request. * 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 and its semantics, user visible functions, classes, interfaces, constants and other user visible constructs. * 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 decision - Decision on a technical aspect. @@ -98,7 +97,7 @@ Should the number of TC members fall to zero, the senior-most Release Manager of ==== Work flow ==== -The TC is primarily a reactive body, and is not expected to proactively search PRs for issues. However, TC members +The TC is primarily a reactive body, and is not expected to proactively search for issues. However, TC members 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. @@ -106,8 +105,7 @@ Should a dispute or question about a change arise, the TC may be called on to re - 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 extension maintainers as appropriate. + * The TC SHOULD consult with relevant other individuals, including the core developers involved in the issue, Release Managers, and impacted extension 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. @@ -136,11 +134,12 @@ The RFC process will continue to be used for process changes, including changes === Technical changes === 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 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 implementation would result in introduction of new bugs, side effects not mentioned in the RFC, significant performance -penalties, 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 TC finds more appropriate. 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 @@ -148,7 +147,7 @@ sees best to ensure the quality and maintainability of the code at the time the Technical aspects on which the TC may make a decision include, but are not limited to: - * Whether a given PR implements a feature or resolves a bug. + * 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. @@ -156,7 +155,7 @@ Technical aspects on which the TC may make a decision include, but are not limit Once an issue has been brought to the TC, the Secretary must allow all TC members time to offer their input within one 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. +members. The vote may 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 simple-majority, with no quorum on a binary question (which could be yes/no or either/or, depending on the situation, From 59e02b5b768143e9164a78827ead93e3072d2eae Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Thu, 16 Mar 2023 13:16:29 +0000 Subject: [PATCH 20/38] Use files for OWNERS as there might be more of them --- rfc/php_technical_committee.wiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 9882329..6272d73 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -26,7 +26,7 @@ definitions: * contributor - Anyone who has already contributed 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). - * maintainer - person responsible for extension or SAPI that is listed in the php-src EXTENSION file or the php-src OWNERS file if added in the future. + * maintainer - person responsible for extension or SAPI that is listed in the php-src EXTENSION file or the php-src OWNERS files if added in the future. * issue - php-src GitHub issue, including pull requests. * process changes - Any changes impacting the way how PHP project is managed and its bylaws. * pull request - php-src GitHub pull request. From 248b07139a15997a96d69b0e1e57904eec995ef3 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Thu, 16 Mar 2023 13:19:07 +0000 Subject: [PATCH 21/38] Some further maintainer clarifications --- rfc/php_technical_committee.wiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 6272d73..9573f49 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -26,7 +26,7 @@ definitions: * contributor - Anyone who has already contributed 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). - * maintainer - person responsible for 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 EXTENSION file or the php-src OWNERS files if added in the future. * issue - php-src GitHub issue, including pull requests. * process changes - Any changes impacting the way how PHP project is managed and its bylaws. * pull request - php-src GitHub pull request. @@ -105,7 +105,7 @@ Should a dispute or question about a change arise, the TC may be called on to re - 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 extension 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 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. From 57ba0c9077aa3b42f790686a1c905cd6b210e052 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Thu, 16 Mar 2023 13:23:26 +0000 Subject: [PATCH 22/38] Remove bylaws term --- rfc/php_technical_committee.wiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 9573f49..9b9b495 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -28,7 +28,7 @@ definitions: * 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. * issue - php-src GitHub issue, including pull requests. - * process changes - Any changes impacting the way how PHP project is managed and its bylaws. + * process changes - Any changes impacting the way how PHP project is managed. * pull request - php-src GitHub pull request. * RM - PHP release managers. * user facing changes - Changes in PHP language and its semantics, user visible functions, classes, interfaces, constants and other user visible constructs. From 08929c297d0e88c67fe63d5d36e9676bfae53f66 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Thu, 16 Mar 2023 13:44:59 +0000 Subject: [PATCH 23/38] Add Larry to authors --- rfc/php_technical_committee.wiki | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 9b9b495..48e6f8d 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -1,7 +1,7 @@ ====== PHP RFC: PHP Technical Committee ====== - * Version: 0.2 + * Version: 0.3 * Date: 2023-03-03 - * Author: Jakub Zelenka, bukka@php.net + * Author: Jakub Zelenka (bukka@php.net), Larry Garfield (larry@garfieldtech.com) * Status: Draft ===== Introduction ===== From a3b3967d47420ae909247ec2439fbe946f440ed7 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Thu, 16 Mar 2023 15:43:13 +0000 Subject: [PATCH 24/38] Set TC vote as private --- rfc/php_technical_committee.wiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 48e6f8d..cd25e3f 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -155,7 +155,7 @@ Technical aspects on which the TC may make a decision include, but are not limit Once an issue has been brought to the TC, the Secretary must allow all TC members time to offer their input within one 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 private and conducted however the TC chooses. +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 simple-majority, with no quorum on a binary question (which could be yes/no or either/or, depending on the situation, From 2e054153df45da31b9729c77ed5e1be5cf5efd4b Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Fri, 17 Mar 2023 10:34:24 +0000 Subject: [PATCH 25/38] Reword introduction in TC RFC --- rfc/php_technical_committee.wiki | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index cd25e3f..4cba754 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -6,10 +6,10 @@ ===== Introduction ===== -PHP uses its voting system to decide about changes to PHP. This was created mainly for user facing changes. It works -well for that purpose but it is not that effective for deciding about purely technical changes that impact PHP -internals and extension API's. It is not clear how it should resolve conflicts on the technical basis between -contributors that sometimes happen. +The Open Source project that develops the PHP language and its reference implementation uses an RFC process to discuss +and vote on proposed changes. This was created mainly for user facing changes. It works well for that purpose but it is +not that effective for deciding about purely technical changes that impact PHP internals and extension API's. It is not +clear how it should resolve conflicts on the technical basis between contributors that sometimes happen. ===== Proposal ===== From 67f3eb5519fb72480d41be29031f16bbfdc47326 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Sat, 18 Mar 2023 20:05:22 +0000 Subject: [PATCH 26/38] Update rfc/php_technical_committee.wiki Co-authored-by: George Peter Banyard --- rfc/php_technical_committee.wiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 4cba754..7507375 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -139,7 +139,7 @@ not about PHP API. 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 -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 or by RFCs prior to the TC's creation. However, it is NOT REQUIRED to abide by them, and may make decisions as it From 858aba3d8e7275cdbff0cab0b9a18088b61db37d Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Sat, 18 Mar 2023 20:10:11 +0000 Subject: [PATCH 27/38] Increase the TC voting period to two weeks --- rfc/php_technical_committee.wiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 7507375..843d021 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -157,7 +157,7 @@ Once an issue has been brought to the TC, the Secretary must allow all TC member 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, as determined by the Secretary). Members may explicitly abstain, and refraining from voting counts as an abstention. Abstentions do not count toward the result. From 8fd3ad98ac79f81979c8ec3ae56536a950567983 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Wed, 22 Mar 2023 20:46:14 +0000 Subject: [PATCH 28/38] Clarify vacancies Co-authored-by: Larry Garfield --- rfc/php_technical_committee.wiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 843d021..8b5a5e9 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -85,7 +85,7 @@ The newly elected TC members will elect from their own number a TC Secretary by 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. -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 number of TC members is reduced to three or fewer and there are more than two months until the next regularly From 1a579e6562d20abd053f789504ba77efb8b2f75f Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Wed, 22 Mar 2023 20:47:42 +0000 Subject: [PATCH 29/38] Update TC vote Co-authored-by: Larry Garfield --- rfc/php_technical_committee.wiki | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 8b5a5e9..cac36d2 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -153,9 +153,7 @@ Technical aspects on which the TC may make a decision include, but are not limit === 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 -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. +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. 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, From c96690eec5b27eeeafd21e5da672be690ebead9c Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Wed, 22 Mar 2023 20:48:43 +0000 Subject: [PATCH 30/38] Clarify removal of TC Co-authored-by: Larry Garfield --- rfc/php_technical_committee.wiki | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index cac36d2..cd018d8 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -113,8 +113,7 @@ Should a dispute or question about a change arise, the TC may be called on to re 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 one month, then the entire TC -is considered AWOL and 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. From f21942ec57c5dd198629a7ca18692300f8283633 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Mon, 3 Apr 2023 11:30:11 +0100 Subject: [PATCH 31/38] Update rfc/php_technical_committee.wiki Co-authored-by: Matthew Weier O'Phinney --- rfc/php_technical_committee.wiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index cd018d8..05bec24 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -8,7 +8,7 @@ The Open Source project that develops the PHP language and its reference implementation uses an RFC process to discuss and vote on proposed changes. This was created mainly for user facing changes. It works well for that purpose but it is -not that effective for deciding about purely technical changes that impact PHP internals and extension API's. It is not +not that effective for deciding about purely technical changes that impact PHP internals and extension APIs. It is not clear how it should resolve conflicts on the technical basis between contributors that sometimes happen. From 32db419ba73578d1ceeaadbf17c64765ce2b7c51 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Mon, 3 Apr 2023 11:31:03 +0100 Subject: [PATCH 32/38] Update rfc/php_technical_committee.wiki Co-authored-by: Matthew Weier O'Phinney --- rfc/php_technical_committee.wiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 05bec24..8e39b5a 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -9,7 +9,7 @@ The Open Source project that develops the PHP language and its reference implementation uses an RFC process to discuss and vote on proposed changes. This was created mainly for user facing changes. It works well for that purpose but it is not that effective for deciding about purely technical changes that impact PHP internals and extension APIs. It is not -clear how it should resolve conflicts on the technical basis between contributors that sometimes happen. +clear how it should resolve technical conflicts between contributors. ===== Proposal ===== From 1d1ecd053c3e42ddde60527577c236a9804137a6 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Mon, 3 Apr 2023 11:37:29 +0100 Subject: [PATCH 33/38] Update rfc/php_technical_committee.wiki Co-authored-by: Matthew Weier O'Phinney --- rfc/php_technical_committee.wiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 8e39b5a..6224da9 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -28,7 +28,7 @@ definitions: * 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. * 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. * RM - PHP release managers. * user facing changes - Changes in PHP language and its semantics, user visible functions, classes, interfaces, constants and other user visible constructs. From 880c7eb9a85f5005edb79535085eb70f05b7f55a Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Mon, 3 Apr 2023 11:38:32 +0100 Subject: [PATCH 34/38] Update rfc/php_technical_committee.wiki Co-authored-by: Matthew Weier O'Phinney --- rfc/php_technical_committee.wiki | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 6224da9..3652a96 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -43,8 +43,7 @@ To further clarify some of the defined terms, following subsection provides some 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 -interface is not a technical change. +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. For example if there is a proposal to add accessors for PHP classes, then everything that is visible to user space like the constructs and their usage in PHP code is a user facing change. The actual C implementation and tests are From c4a9ce637895f457e1b017ea3e3e394bd58f4a93 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Mon, 3 Apr 2023 12:09:22 +0100 Subject: [PATCH 35/38] TC updates related to feedback --- rfc/php_technical_committee.wiki | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index 3652a96..e59c9d5 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -1,5 +1,5 @@ ====== PHP RFC: PHP Technical Committee ====== - * Version: 0.3 + * Version: 0.4 * Date: 2023-03-03 * Author: Jakub Zelenka (bukka@php.net), Larry Garfield (larry@garfieldtech.com) * Status: Draft @@ -9,7 +9,7 @@ The Open Source project that develops the PHP language and its reference implementation uses an RFC process to discuss and vote on proposed changes. This was created mainly for user facing changes. It works well for that purpose but it is not that effective for deciding about purely technical changes that impact PHP internals and extension APIs. It is not -clear how it should resolve technical conflicts between contributors. +clear how it should resolve technical conflicts between core developers. ===== Proposal ===== @@ -23,7 +23,6 @@ The text contains various terms that need further clarification to prevent futur definitions: * 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. * 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. @@ -43,7 +42,8 @@ To further clarify some of the defined terms, following subsection provides some 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. Put another way, the _definition_ of the user interface is user facing only, while the _implementation_ itself is a technical change. +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. For example if there is a proposal to add accessors for PHP classes, then everything that is visible to user space like the constructs and their usage in PHP code is a user facing change. The actual C implementation and tests are @@ -64,11 +64,12 @@ The TC Secretary is responsible for: 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 -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 -candidate is paid to work on php-src or PHP extensions, they must state in their nomination which company or organization -they work for. Failure to do so will result in disqualification, as determined by the TC Secretary. +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. Once nominations are over, the voting process will begin. Eligible voters are the same as for any RFC. @@ -96,8 +97,7 @@ Should the number of TC members fall to zero, the senior-most Release Manager of ==== Work flow ==== -The TC is primarily a reactive body, and is not expected to proactively search for issues. However, TC members -are permitted to comment on any open issue, and contributors are encouraged to give their comments appropriate weight. +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. From 30d95154cec4fd7f4f62598946f200f1f6edd931 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Sat, 8 Apr 2023 13:29:22 +0100 Subject: [PATCH 36/38] Update rfc/php_technical_committee.wiki MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Co-authored-by: Tim Düsterhus --- rfc/php_technical_committee.wiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index e59c9d5..a79be85 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -25,7 +25,7 @@ definitions: * php-src - Source code in https://github.com/php/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). - * 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 EXTENSION file or the php-src CODEOWNERS files if added in the future. * 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. From ae77414b5fc2d8bcfdc923e6a7f502c100b59c02 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Sat, 8 Apr 2023 13:32:08 +0100 Subject: [PATCH 37/38] Fix formatting in TC --- rfc/php_technical_committee.wiki | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index a79be85..a8cf756 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -1,8 +1,8 @@ ====== PHP RFC: PHP Technical Committee ====== - * Version: 0.4 + * Version: 1.0 * Date: 2023-03-03 * Author: Jakub Zelenka (bukka@php.net), Larry Garfield (larry@garfieldtech.com) - * Status: Draft + * Status: Under Discussion ===== Introduction ===== @@ -42,8 +42,8 @@ To further clarify some of the defined terms, following subsection provides some 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. Put another way, the _definition_ of the user interface is user facing only, while the -_implementation_ itself is a technical change. +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. For example if there is a proposal to add accessors for PHP classes, then everything that is visible to user space like the constructs and their usage in PHP code is a user facing change. The actual C implementation and tests are @@ -101,20 +101,20 @@ The TC is primarily a reactive body, and is not expected to proactively search f 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. + - 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 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 +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. +The election of a new TC will "reset the clock" on any outstanding ''tc-hold'' issues. ==== Decision process ==== From c12969baa2a754fe0c2dbc9ce54a8b9b43c4e946 Mon Sep 17 00:00:00 2001 From: Jakub Zelenka Date: Sat, 8 Apr 2023 13:33:05 +0100 Subject: [PATCH 38/38] Use only CODEOWNERS for extension maintainers --- rfc/php_technical_committee.wiki | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfc/php_technical_committee.wiki b/rfc/php_technical_committee.wiki index a8cf756..724a9f6 100644 --- a/rfc/php_technical_committee.wiki +++ b/rfc/php_technical_committee.wiki @@ -25,7 +25,7 @@ definitions: * php-src - Source code in https://github.com/php/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). - * maintainer - person responsible for core subsystem (e.g. extension or SAPI) that is listed in the php-src EXTENSION file or the php-src CODEOWNERS 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. * process changes - Any changes impacting how the PHP project is managed. * pull request - php-src GitHub pull request.