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: [RFC] Warnings for PHP 8.5 - Externals
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
