Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128640
Precedence: list
MIME-Version: 1.0
Date: Fri, 05 Sep 2025 12:22:35 +0200
To: Rob Landers <rob@bottled.codes>
Cc: Larry Garfield <larry@garfieldtech.com>, php internals
 <internals@lists.php.net>
Subject: Re: [PHP-DEV] [RFC] Clarify discussion and voting period rules
In-Reply-To: <73866cf1-6ac9-4e30-9273-0634cea43352@app.fastmail.com>
References: <53cdbf5b-7c6e-4ba1-9987-332634cab527@bastelstu.be>
 <4624748F-0C62-4E3C-81D0-5CDC56FEC55F@nicksdot.dev>
 <c177c3340f458a4de58fefb4107c1753@bastelstu.be>
 <dd1e34df1b5b740948ab24f0b4bd367b@bastelstu.be>
 <68c44ae3-8e1b-419d-9c30-906b9c2d5a81@app.fastmail.com>
 <0f32efec-b6c9-4ec0-96bf-297da722aaf1@bastelstu.be>
 <a8a5b6c7-e84e-426c-9c0c-2905861319c6@app.fastmail.com>
 <7ab7580d355569eed3d69aec92dacd4c@bastelstu.be>
 <73866cf1-6ac9-4e30-9273-0634cea43352@app.fastmail.com>
Message-ID: <af4c3e86cf89cdc6720226412e57c4dc@bastelstu.be>
Content-Type: text/plain; charset=UTF-8;
 format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

Am 2025-09-04 20:17, schrieb Rob Landers:
>> Specifically “Other RFCs” (i.e. RFCs that do not touch the language,
>> which is not actually defined) “might” (this probably should read 
>> “may”)
>> use a “smaller timeframe” that “should be at least a week” (i.e. it 
>> may
>> also be 2 hours). In other words, that policy is completely useless to
>> resolve any cases of disagreement, since it allows basically anything.
> 
> So, someone could create an RFC, saying "Jo ElePHant, III" is 
> "President of PHP", set the voting period for exactly one minute, vote 
> on it themselves, and close the vote, and whomever "Jo ElePHant, III" 
> is, would have to be the President of PHP before the announcement email 
> is even delivered to the entire list?

That is my understanding of the current policy, yes.

> Somehow I doubt this would actually fly, despite "maybe, technically", 
> being within the rules.

Sure. It would also possible to follow-up with a new “proper” RFC that 
reverses the previous decision. You were using an extreme example, but 
we a case in PHP 8.5 where the discussion period arguably was cut short: 
https://externals.io/message/128040#128272

> I think the more you make a policy pedantic, the easier it is to play 
> pedantic games. I had a couple of hours to sit on the train and think 
> through some loopholes in the current proposed text:
> 
>  1. The 336 hours is oddly specifc. It also begs the question: "what 
> about leap seconds?" Could someone cause an entire revote simply by 
> pointing out that the vote closed one second earlier than 336 hours 
> because one of those hours had one less second? Does it matter? Perhaps 
> saying "~336 hours" to drive the intent home without saying "exactly" 
> that amount of time?

An hour is well-defined to be 3600 seconds. Leap seconds are a concept 
of “date and time”, but do not affect how much time has actually passed. 
After 2035 there will be no more leap seconds and given the slowing of 
Earth's rotation it seems unlikely to have any more leap second. In any 
case it is easy for an RFC author to completely bypass this question by 
treating the specified lengths of time as minimums, which is likely to 
implicitly happen anyways.

>  2. Just about any change could be construed as an "obvious typo" or 
> "editorializing" A stronger definition could be "any change that 
> clarifies but does not alter the meaning (e.g. "frrm" -> "from" but not 
> "form" -> "from"), while changes that affect APIs, semantics, or 
> options are never typos". Even then, someone could just create a stub 
> and simply argue that all their edits are clarifying the stub... so 
> this one will be tricky.

I believe this is sufficiently handled by the “when in doubt treat it as 
a more significant change” and the list of examples of what constitutes 
a major or minor change. The proposed policy specifically says that 
“clarification” is a minor change and that anything that would lead to a 
change in implementation is a major change.

>  3. Forbidding starting/ending on Dec 17->Jan 10 will probably 
> backfire. It would behoove someone to schedule a voting start on Dec 
> 16, so that it would end on Jan 11. Albeit, that is longer than 2 
> weeks, but it's shorter than waiting until Jan 11 to start a vote... 
> arguably, this is probably worse than what the rule intends to solve. 
> If the concern is holiday churn (heh, uninitentional rhyming), it might 
> be better to forbid *starting* during that period, but let existing 
> votes play out as normal (and maybe picking a sooner date).

Starting on December 16 and ending on January 11 would be fine for me. 
I've intentionally added some buffer space so that anyone interested in 
participating in the RFC process should find the time to cast their vote 
after they followed the RFC discussion and thus had the opportunity to 
make up their mind. Besides “New Year’s” and “Christmas”, I've 
specifically also accounted for Eastern Christianity Christmas (relevant 
for Russia) which is on January 7th.

>  4. The official start and threading is ambiguous. For example, I can 
> add a coauthor on my RFC. Then "announce" the RFC by both authors but 
> only have discussions in the later thread. I could move to a vote after 
> two weeks, no matter what is happening in another "unofficial" thread.

I'm afraid I don't understand what you are trying to say here.

>  5. It says that you can't add or change a voting widget, but you can 
> remove them freely without triggering a vote reset.

Removing is the most extreme form of changing one, but I can certainly 
spell that out explicitly.

>  6. It might be a good idea to add "all durations are measured in UTC 
> calendar time, ignoring leap seconds". One could argue that announcing 
> the vote at 11:59:59 Monday and starting the vote at 00:00:01 Wednesday 
> would satisfy the 2 day/48 hour rule by arguing time zone shenanigans.

The hour-based definition is already independent of any timezones.

>  7. If a vote ends at 15:09, does it actually ends at 15:09:00, or will 
> votes be accepted until 15:09:59.99?

I'm happy to clarify this in the policy. Similarly to deadlines in the 
real world this would be understood “until, but not including”, i.e. as 
long as the clock doesn't show 15:09.

>  8. vote extension hack: can someone change a vote end-date after the 
> vote has already started? Thus if the results are unfavorible, can I 
> simply just extend the voting period until I get the results I want, 
> literally increasing it by 24 hours every day until it passes by simply 
> stating "I am still on holiday"?

No. The end date must clearly be specified in the email announcing the 
vote. You are free to select a longer interval right away, but once the 
vote started, the decision is locked in. I can spell it out more 
explicitly that the RFC (including the voting rules) may no longer 
change once the vote started.

> The new rules could allow some creative people to bypass the cooldown 
> period altogether:
>  1. Someone could create an empty RFC, and announce it. Then "clarify" 
> and "editorialize" the RFC (easier to do with a coauthor to back you 
> up) minutes before the two weeks elapse, then call a vote, with most 
> people having long dismissed the empty RFC as junk.

I believe I answered that with bullet point (2) above.

>  2. You could simply create a v2 of an RFC minutes/days after the 
> failed vote and go straight to a vote; claiming the cooldown started 
> from the original RFC.

I don't see how that would be possible even with an intentionally 
“malicious” reading of the policy. The policy specifies that the 
discussion period of an RFC starts with the official RFC discussion 
thread matching the title of the RFC and linking the Wiki page. Thus any 
existing discussion clearly is not applicable to a newly created RFC.

Best regards
Tim Düsterhus