Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:129229 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by lists.php.net (Postfix) with ESMTPS id 2067F1A00BC for ; Sat, 15 Nov 2025 12:09:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1763208571; bh=dw4I2NLsL2rIQX+NfWmKdDoZZ+67HZn7YOHtm1wI0Jc=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=Je57UW+/U07exLEOsb1XT+R4r22TxV0WgUsScVvtc9gVBmCJ81sDuWG/cM3sgPH/E fCCA3AO2LjtBi0qRAQ0LguKi1tbRuRCcO3bJ4+A+VZURej/oJ5ua25z3Yey8cxXMWa hfMsyU8XNN6mGpcIRJtJp+hiU1Cts2TOO7vcu5Rs2DWL5/8YjiupDf1vww86UM9n6h +5uy3TUkduX5Q+hfJlamC0CAdgyf4XOQiBWSIcJobkJ527ZvaAWvFKEv9bHl3wH9K3 pAzdIDM6Ow1CeLjXPRBa/akl+0rVps4QSckoe37aKngY/dPcujy0E14XXvg7shMXiJ jsZu4QDuemWvg== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id A30561801D5 for ; Sat, 15 Nov 2025 12:09:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.9 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_50, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE, RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=4.0.1 X-Spam-Virus: No X-Envelope-From: Received: from GVXPR05CU001.outbound.protection.outlook.com (mail-swedencentralazolkn19013072.outbound.protection.outlook.com [52.103.35.72]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (secp384r1) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Sat, 15 Nov 2025 12:09:30 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=K0MSHsokNreJSS/Tow1hHWr1jS9iLJIlipqOXOENcp+/UcRjE0CB7v/2a5mZTt1aTeR2AUK7Zvfb/sB2688bJIselKq6IIh1iDO0oI0hUQshu4sx6Bf1Mzkwve3ExCh1sNh+vX3kAPuy8EvBZHnuIXbXPpvUlhnPVSYqcPRzuRgpIUmrvAjR6XVE2PpxtnrUL4KSoijJ/FmqlViOIFXdYdo5Dwty/sVlMxtVPFgC/iVe9N/4RAPBU+KmbLGz30W4Ng/FFgaXl+5qpFcsgiJ9awYqRyk8hOeQSIdyQ3sAGKC1qFDT3Aq8TrSikVvka9LFPShx30TTezh6FOA7C/JCjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hJmwu+9+h5GPIA7Ok+Y+LGrWRgy1xbOOuoy9PjwPLMA=; b=lxT6OWPULfgRtwcIGIuacUjY+/juT4bRyzMzA5DwVxvK9LzmwTrTA/7Lkgo/adbm7ikIyXH4s+lL1SAFTu8TYAq3eh8BwT9XE2rTA13nsKGY9U8UoI8rP6FNlb7o7VvnppIA4sIBzzgfgOLHtFtl6M8ODFwAfVckRzsd5J2YPS6vgqXU1yhRdq+cMpDi/iXruRvlTAxZ7MXfobXblZk+4+UPN+uAvYybKLJama8lqYyAeozLH/R6jWR6yfzz/pHR9quBxoWl9mmp8f51htU2RR7RrSqx9L4T87rxWtwLbz+p4U+cDuUEDsrrCwH5pD0EHQc0uEbGgnDMD82PfPntLQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=hJmwu+9+h5GPIA7Ok+Y+LGrWRgy1xbOOuoy9PjwPLMA=; b=C5JsSO+kbW+adduey3NPCbAy6ChuBIb/YjIrRirnOTyKyOPrynoFha+Vb9wGHnhqgVMdl07PayQJN7gmiiNfFjRbGFercBdZLfNHHdxjh16c67PsLvKDwv/SeVyriEO1XOTtrtkbJlue7XgNjU3wkiKNihJWY01i5Y+LuX/BlfsBGHSjBmbNOsrJa3wbmcA/qdaWAxzfsT3Pu3y7Hsci5GQTlbRlYJSKry21bNV/WWgsQsLLoxOFsEw6oUH25U54hG9mY0Xz1dBJLhGuKtM2P53BFweQsjpwZdRGSCkL9+a4xsSdIn85F4sDIwRTDHgXEg7VLBo4a41QCy9FtBUcuQ== Received: from AM8P250MB0170.EURP250.PROD.OUTLOOK.COM (2603:10a6:20b:321::21) by AS2P250MB1016.EURP250.PROD.OUTLOOK.COM (2603:10a6:20b:594::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.9320.18; Sat, 15 Nov 2025 12:09:23 +0000 Received: from AM8P250MB0170.EURP250.PROD.OUTLOOK.COM ([fe80::651e:bbd2:b18a:80ff]) by AM8P250MB0170.EURP250.PROD.OUTLOOK.COM ([fe80::651e:bbd2:b18a:80ff%3]) with mapi id 15.20.9320.013; Sat, 15 Nov 2025 12:09:23 +0000 Content-Type: multipart/alternative; boundary="------------h96hx0GPCksdIbeI4aG7ma8A" Message-ID: Date: Sat, 15 Nov 2025 13:09:21 +0100 User-Agent: Mozilla Thunderbird Subject: Re: [PHP-DEV] [VOTE] Clarify discussion and voting period rules To: Nicolas Grekas , =?UTF-8?Q?Tim_D=C3=BCsterhus?= Cc: php internals References: Content-Language: en-US In-Reply-To: X-ClientProxiedBy: FR4P281CA0120.DEUP281.PROD.OUTLOOK.COM (2603:10a6:d10:bb::8) To AM8P250MB0170.EURP250.PROD.OUTLOOK.COM (2603:10a6:20b:321::21) X-Microsoft-Original-Message-ID: <2a6df819-d6eb-46b1-b65c-7f3dc68c1e01@hotmail.com> Precedence: list list-help: list-unsubscribe: list-post: List-Id: x-ms-reactions: disallow MIME-Version: 1.0 X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM8P250MB0170:EE_|AS2P250MB1016:EE_ X-MS-Office365-Filtering-Correlation-Id: 06d8caf3-b1c5-4824-d78b-08de243fd013 X-Microsoft-Antispam: BCL:0;ARA:14566002|41001999006|51005399006|19110799012|12121999013|15080799012|12050799012|8060799015|23021999003|9400799040|461199028|5072599009|1602099012|40105399003|440099028|3412199025|4302099013|10035399007|26104999006; X-Microsoft-Antispam-Message-Info: =?utf-8?B?VmtlcTNxTE9xZ1dyZU9wbEJPNzBJanJNdFlsZnZJdjBxckhYaTQxNDZscmhX?= =?utf-8?B?VjNQSkdzK21uem8wUXZkTWd5eWtxTVBzVXIzYUdPbStLQ0VPQ3lUWm9nUzBP?= =?utf-8?B?MTg1Z1lISnkxUWs1RTJYYWR1RjV3eUlrQW1VN2VpVEJwRFR3T3M5eTRPcWN3?= =?utf-8?B?am5hVWN2bkhsc2FENGFUbGJOM2JHOE5YYkVvNzV5c0YwYVpPVTdLWTlSSGxu?= =?utf-8?B?K1kwaFJjc1RWTmEyMWpRK3ZWeXpIcG5KRVhDck5UR25tZE5naHlYKzFkbTdT?= =?utf-8?B?d3RMWXBvV0tSYVNGSDdTVlVSUm5RNGptaW9xTlJKUUt1SVIrUWxBL2VHV29i?= =?utf-8?B?NkdvVXF2M085cHJXV25CNkZUNjJwc2MyOHNoOVFuTThGQ2pXLy9neUVYblVF?= =?utf-8?B?eTZWaTRRM3FwQXJmVVhRQVZqUE9HZkc0UnozaE8xS3djNTRnUFBzMzVsSTR5?= =?utf-8?B?VEx1ckhCYng3OElCN1JCTDR0OUZsbkJhRFdWVHBweFhBaGNidUJqaFk5N0M0?= =?utf-8?B?em9FUGV6Z25kTHpvcmx6ZmpUMDdxTW9odUFzYVkvL250WlFvK21ZWGg1ZFQx?= =?utf-8?B?Q1BRUzVDS2lsSkRGaEtUV212RklIV2FXUmJEUjZ1SXRQRlVmWWJMYzZGcklH?= =?utf-8?B?VG91TEV5NkE4eGN3ajFlTFRMS1ptR2t6V1FhTVVNRFRQd0pDZVlQS1JOV0M2?= =?utf-8?B?T21LeGkvRGF6Uk5hdjBXRzMrNTNRYUZIM2s4elI4UXUwSE1nOTE3QW9ubTQ3?= =?utf-8?B?ZWs5eEw2YXpKVENYdWxmTDNGckdjNnowSUM5WG5oOFdEUWMrNHBDN1hhUXd2?= =?utf-8?B?MUcxalhoMHgxbHMvbHFFOFg2dnhlMWx3ait0OEtHazBvU0pPRnE5YWdzODhL?= =?utf-8?B?bkZiT2oxNlJRbGsvV3V0NHdpdHVsZUJTUG9vNEJDd1lVeXZjYjFWQS96bGQy?= =?utf-8?B?SWIrQlh4WkgrN3RMc2tNK0pIc01KMTAxT3d0RnJ5ck9RUitxSE4yRzZqSTFa?= =?utf-8?B?Wno5ODllb0dUOUFOZ0gwckpSdTVvQzBQQW1waDdPTU5NTXgvZndSMFE1ZDI1?= =?utf-8?B?Mlk0dnhRSndsZFJ6U0ZVY0JYQW9OdEMyQ2RpMGNkZUdHUVhmK2JYRXNZZFV3?= =?utf-8?B?bnlUUmJmaERBR3kzS3R3OXhoMEhPcmVOdHhRWjBRTHRNY0ZrWmh4aUdIbzgr?= =?utf-8?B?VnNaME0zMkY4Q1AvOUoyaFFQQXEyS1l5TjJ2RnRqUlFZRnJEcGdFd3FqVkp0?= =?utf-8?B?UFZyUDhVRklLamNTeGNzRGIvclBkbG1sLzZ6eU55eFQrUTd2TFQzRTJCLzZm?= =?utf-8?B?cG1Eamd0MXRIMDVCMmx1QXJBZ25neGhtRGU4d1JNRXR3b213djVNd3pEcjk0?= =?utf-8?B?WXhIS2hId0xWV1pNdllBZnFmcXNUbVgrcTVvL3RBcjJsenRuOXZWS2hHWkxs?= =?utf-8?B?ZUxheUdGaGNNcWpBMlRYajQ3emMyN0dOU096ajAwYk82YVBld091RklFaGRY?= =?utf-8?B?YjM4R3ZIckVCVktITkk1YU5iM1VCM3ZsUkZad0ZKUzdnVWo2UnYwa2t3dzg3?= =?utf-8?B?WlNHMjRiQVZxK0Z2TmVEV0tRbjVjKzNEOVdodGVtZjVkN1l3Q1hBWEhTSDAz?= =?utf-8?B?OHZ2bnlZdngwVHJnZHNneHB0NnY1ZmMvV3FKWUFsN2tZQkFCNm5pOExyZlJo?= =?utf-8?B?Njc0ODE5Mmd3UnV1NmdJdEZEdlFSS3NqYmpUR0hrZGJKL2ZRbW9XTlNmNkk5?= =?utf-8?B?WUdrSk1GSk9MYVhzOTZIdXhuaWtlUm44YlpJNDI5dHg4a1F3N2tnM3U3SE4w?= =?utf-8?B?czZuY0NiSmRIZE9MVWhuL0prUFdlVElURXJ2am5taTVBcXUxTlRvTStRYVZ0?= =?utf-8?B?ZjM0b2JCeVRhK3FYUS8zWEZrZXVPcndVTk93M1J6TEZnR2hvWnI0dXNKUWU4?= =?utf-8?Q?LPS8w6YQqk8=3D?= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?K0JQeTRjdWFIZGN4NTZPU1RhQnVpcUpSTEZYZ0ZqNzd0RnRrU3VrNVBQaGk0?= =?utf-8?B?VG41OFB0cEdSbFZQUkJKcjl2TFJNZWFUQ3FQc0xCRHREMXNMaVpGc3dzYTlM?= =?utf-8?B?RDBBeG03d09Jb2ovOXNUUUphVitiQmFhMkI5ZWVhU0ZDWWpZaGdJRC9nUmJL?= =?utf-8?B?TlluTFgvZUdXYkpqQnBiSkh2RWswcmV6OUl6NUFwa3crSGhtQ1FuazJxVDhm?= =?utf-8?B?MVJMUkNpM1dDTzg4anI5NWdiOTgxZC9zWDdsMEs5dlo3bWt1elN3WVBsMml6?= =?utf-8?B?amZDcFVCZ3NZVHZQODVTM3k5MlJKaS9DbHlrelhSQVFQNWpXSVAveWFoV2tT?= =?utf-8?B?aHpSQ3dxYUJJQmptZXNqWGFyTFZHOUlRQkRvbkovbUlUV29FakowOVdCMUdD?= =?utf-8?B?cDNXZnc3ZEk5Vkpqc0tCTGdjVWxTU0VCL3R5ZzgxUndMTkwvTnYxNU4ycy9y?= =?utf-8?B?RC92UDhiN0F5NC9RSFZlTTFvN3g3NUhUQVoyenRLZzF4cnRCMUw0Q2liS05n?= =?utf-8?B?N1R0OWo3N0t3eDhEVFl4WG1aYWFjVzlONnhjZExRUXZpRWVpVzZwOU5UWDVG?= =?utf-8?B?R3NWTC95RlFRSXBwMnE5WVdrOUZMbTY4TTlvVXkzNUs4MDJFOVI2UEY3UnQx?= =?utf-8?B?TDJJWXJrVFV5QVhLak50WGNCL2pkODlGWW0xMU1ScURQRENjVXQ1bzBvWFgy?= =?utf-8?B?d0p2M3RSTTc5WVhWMWlORXBYbmpxcVJQZW55c09NS3V0NGxncGRNUWlIMGlO?= =?utf-8?B?NmpydGNRWWtmYmNvdDhZMTVhNFZGcDIyS3Y5emRuTmJ0Zkd3Q05GNEhJS1ky?= =?utf-8?B?TEZiaURMYklPeWVnSmtZbW9NQ1FmRWo3dEUxUC9wamhFa05OZXBpTmlocFBK?= =?utf-8?B?eWlmS1hrRjBhK0lXRVc0VlorS0xROHcrWHdFSjVJNFZkelpTZlRyZFUxN25l?= =?utf-8?B?elZjemdMSFR6dmhzRGs3NlNhUXR4Z2hnR0c2V2dnc3BHamxKUjFMa1dhSUJ1?= =?utf-8?B?dWhVbXdGVWRwU2NoVFhaWkNzaGE2d2dNdUlpYXJHWmFCd2dhYkZ4VnBmRmZo?= =?utf-8?B?ak4xL2xsZWNIZ09nbFR6NVVLTWc5bkVmR3pUT1VGN1g4VVF0ODhoYjMwdjVM?= =?utf-8?B?dEM4dFRhd3FRVTliRzBNQ2V6ZWtqOEYvSytadDJYanZmVnZWd2dYNnU5cXlW?= =?utf-8?B?ZGRUemFObkJSN2FNWVV2eFZMQTY0TE0rMUFWUTltbGdMNlRRRit2Z3k5V1pC?= =?utf-8?B?UGtTNkR5cUVyUW9QK29OQ29XQlJEQjFVUXZVb1ZlVnczN1EycTBKMzB0eWVH?= =?utf-8?B?M3Zra2J1OVR5L2ZaNHZQTzgyWW80YmlVMzV2Z04veHZaM2p4RDE5Y1lJZDF1?= =?utf-8?B?dDlrNS9ORE9ycHNpVCtLVHRjT2kxYTVGKytuWGxOeXZkWFpCeG1DRTM5OVZG?= =?utf-8?B?RVBOWXkwanRxYnlJNnpXaTVmbm5FTWIycHY0Y3o5czArcmhtY09VSm5aWmFK?= =?utf-8?B?VGdRaG5xSFc3amtRSnFPbmZDeUJid2JqZ05LeVgxbUZOa1BCMWxKbzVvOEJr?= =?utf-8?B?RkpMR1VJSUpONkc4NEFkeDNKdVNaU1prVlRsMFE0M1c4alZYWi9SaGZtVWUx?= =?utf-8?B?TFB1MjZXTEoxMDZYcnd5cS9oc0JCYVFWM3ErM2kydW8wTTdQU1ZqTXIyWlh1?= =?utf-8?B?aWtIdE1jdWFxUHdMSldVQUs1V2V6ckh5bXErRHZxVTdRQXVTa2s2UDFnK2U4?= =?utf-8?Q?oSwZlYv8KwfSAjbN7k=3D?= X-OriginatorOrg: sct-15-20-8534-15-msonline-outlook-5f066.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 06d8caf3-b1c5-4824-d78b-08de243fd013 X-MS-Exchange-CrossTenant-AuthSource: AM8P250MB0170.EURP250.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Nov 2025 12:09:23.0352 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS2P250MB1016 From: bobwei9@hotmail.com (Bob Weinand) --------------h96hx0GPCksdIbeI4aG7ma8A Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hey, On 15.11.2025 10:19:29, Nicolas Grekas wrote: > Hi Tim, everyone, > > > Hi > > I just opened voting on the "Clarify discussion and voting period > rules" > RFC. Please find the following resources: > > - RFC Text: https://wiki.php.net/rfc/rfc_discussion_and_vote > - Implementation PR: https://github.com/php/policies/pull/23 > - Discussion Thread: https://news-web.php.net/php.internals/128594 > > The RFC contains a single primary vote requiring a 2/3 majority. > Voting > will close 2025-11-20 09:30:00 UTC. > > ---------------- > > As during the discussion, I'd like to explicitly spell out some of > the > things that I took into account. > > It is now 2025-11-06 08:54 UTC (and will be a little later when I > actually hit send). > > - The last change to the RFC was a Major Change on 2025-10-23 > 07:37:43 > UTC: https://news-web.php.net/php.internals/128921 > - The Intent to Vote announcement was sent on 2025-11-04 08:45:24 > UTC: > https://news-web.php.net/php.internals/129063 > - There was no further feedback to take into account after the last > Major Change (and thus neither after the Intent to Vote). > > A little more than 14 days have passed since the last major change. A > little more than 2 days have passed since the Intent to Vote > announcement. Both is strictly within the proposed rules. The RFC was > not inactive, since the last email was my Major Change announcement, > which happened less than 42 days ago. > > This email contains all the necessary information, namely the link to > the RFC text, Discussion Thread, a list of the number of votes to > cast > and the end date. I also included a link to the implementation, since > this is the main relevant thing for a policy RFC. Voting will close a > little over 14 days from now. I have specified some buffer room to > account for “mail delivery delay”. > > I will make sure to add a link to the archives of the voting > thread as > soon as I see it appear in the archives. > > > > After chatting with a few, I decided to vote against the RFC. > I do appreciate the effort to formalize our unwritten rules. > Yet I'd summarize my vote as: too many MUSTs, not enough SHOULDs in > the proposed policy. > I do think it's important to clarify the rules for occasional > contributors, and MUSTs make things more annoying to me, not smoother. > Also, despite the intro of the RFC, it goes past just clarifying > current rules: it adds MUSTs on things we are fine agreeing to case by > case at the moment. > I wish common sense still remains our main approach, and the RFC as > proposed makes me feel we go into more bureaucracy. > And to me, bureaucratie makes things smoother only for the experts of > its own rules. > Thus my vote. > > Cheers, > Nicolas I completely agree with Nicolas' sentiment. The RFC process MUST be mostly guidelines, with few hard rules which govern the fundamental requirements. For example, you SHOULD not make changes to RFCs during voting periods. But you MAY make them. For purposes of clarification, for changing a detail which was pointed out very late, but is not material to the overall RFC. Even when it would actually qualify as a "Major change" according to your definition, but actually is very minor. As a made-up example, if a pattern matching RFC would discuss the order of destruction of the arguments provided to the pattern in its RFC. And it turns out, for someone who played around with the implementation, that the RFC text did not fully match the implementation. It's a detail, but still qualifies as semantics. And it's unlikely to change the minds of the voters. This would be a textbook example for me, where a RFC text SHOULD be adjusted, the list notified, but the vote be maintained, and not cancelled, nor a grace period observed. If people then object to the non-cancellation, because they consider it material enough, then the vote MUST be cancelled. In short - not all "major change" is actually major. Same for "minor changes" - your definition calls every single addition of an example or clarifications as minor change. Are you intending to discourage RFC maintainers of adding new examples shortly before a vote, when internals participants point something not fully explained? So that the vote just may happen when the RFC maintainer intended it, instead of - as you mandate - a week later. Sounds nonsense to me. Instead, similar to changes during voting period, make it a judgement call for the maintainer, and allow voters to request an extension of the discussion period, if they disagree. Also I don't like the requirement, that the RFC text shall be immutable, except for the errata section, in particular before a GA release. In particular minor RFC implementation details sometimes do change, e.g. due to conflicting semantics, implementation difficulties with specific edge cases etc. You say it's for the errata section. But I disagree. The RFC text should mirror, what is being introduced to the language ultimately in a GA, also as a proper reference for later readers including documentators, and the errata section should tell what the prior state was (in case you are interested in knowing the voted on version, essentially). Or the holiday requirement is not flexible enough. Why not say "MUST NOT both, start and end, within ..." so that you may start or end a voting period there, but it will be open for at least a bit outside of the window, too. Thanks, Bob --------------h96hx0GPCksdIbeI4aG7ma8A Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hey,

On 15.11.2025 10:19:29, Nicolas Grekas wrote:
Hi Tim, everyone,


Hi

I just opened voting on the "Clarify discussion and voting period rules"
RFC. Please find the following resources:

- RFC Text: https://wiki.php.net/rfc/rfc_discussion_and_vote
- Implementation PR: https://github.com/php/policies/pull/23
- Discussion Thread: https://news-web.php.net/php.internals/128594

The RFC contains a single primary vote requiring a 2/3 majority. Voting
will close 2025-11-20 09:30:00 UTC.

----------------

As during the discussion, I'd like to explicitly spell out some of the
things that I took into account.

It is now 2025-11-06 08:54 UTC (and will be a little later when I
actually hit send).

- The last change to the RFC was a Major Change on 2025-10-23 07:37:43
UTC: https://news-web.php.net/php.internals/128921
- The Intent to Vote announcement was sent on 2025-11-04 08:45:24 UTC:
https://news-web.php.net/php.internals/129063
- There was no further feedback to take into account after the last
Major Change (and thus neither after the Intent to Vote).

A little more than 14 days have passed since the last major change. A
little more than 2 days have passed since the Intent to Vote
announcement. Both is strictly within the proposed rules. The RFC was
not inactive, since the last email was my Major Change announcement,
which happened less than 42 days ago.

This email contains all the necessary information, namely the link to
the RFC text, Discussion Thread, a list of the number of votes to cast
and the end date. I also included a link to the implementation, since
this is the main relevant thing for a policy RFC. Voting will close a
little over 14 days from now. I have specified some buffer room to
account for “mail delivery delay”.

I will make sure to add a link to the archives of the voting thread as
soon as I see it appear in the archives.


After chatting with a few, I decided to vote against the RFC.
I do appreciate the effort to formalize our unwritten rules.
Yet I'd summarize my vote as: too many MUSTs, not enough SHOULDs in the proposed policy.
I do think it's important to clarify the rules for occasional contributors, and MUSTs make things more annoying to me, not smoother.
Also, despite the intro of the RFC, it goes past just clarifying current rules: it adds MUSTs on things we are fine agreeing to case by case at the moment.
I wish common sense still remains our main approach, and the RFC as proposed makes me feel we go into more bureaucracy.
And to me, bureaucratie makes things smoother only for the experts of its own rules.
Thus my vote.

Cheers,
Nicolas


I completely agree with Nicolas' sentiment. The RFC process MUST be mostly guidelines, with few hard rules which govern the fundamental requirements.

For example, you SHOULD not make changes to RFCs during voting periods. But you MAY make them. For purposes of clarification, for changing a detail which was pointed out very late, but is not material to the overall RFC.
Even when it would actually qualify as a "Major change" according to your definition, but actually is very minor.
As a made-up example, if a pattern matching RFC would discuss the order of destruction of the arguments provided to the pattern in its RFC. And it turns out, for someone who played around with the implementation, that the RFC text did not fully match the implementation. It's a detail, but still qualifies as semantics. And it's unlikely to change the minds of the voters. This would be a textbook example for me, where a RFC text SHOULD be adjusted, the list notified, but the vote be maintained, and not cancelled, nor a grace period observed. If people then object to the non-cancellation, because they consider it material enough, then the vote MUST be cancelled.

In short - not all "major change" is actually major.

Same for "minor changes" - your definition calls every single addition of an example or clarifications as minor change. Are you intending to discourage RFC maintainers of adding new examples shortly before a vote, when internals participants point something not fully explained? So that the vote just may happen when the RFC maintainer intended it, instead of - as you mandate - a week later. Sounds nonsense to me.
Instead, similar to changes during voting period, make it a judgement call for the maintainer, and allow voters to request an extension of the discussion period, if they disagree.

Also I don't like the requirement, that the RFC text shall be immutable, except for the errata section, in particular before a GA release. In particular minor RFC implementation details sometimes do change, e.g. due to conflicting semantics, implementation difficulties with specific edge cases etc. You say it's for the errata section. But I disagree.
The RFC text should mirror, what is being introduced to the language ultimately in a GA, also as a proper reference for later readers including documentators, and the errata section should tell what the prior state was (in case you are interested in knowing the voted on version, essentially).

Or the holiday requirement is not flexible enough. Why not say "MUST NOT both, start and end, within ..." so that you may start or end a voting period there, but it will be open for at least a bit outside of the window, too.


Thanks,

Bob

--------------h96hx0GPCksdIbeI4aG7ma8A--