On Fri, Sep 5, 2025, at 12:22, Tim Düsterhus wrote: > 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. The widget requires you to specify a datetime that it ends on, not a duration. Meaning the time between the two week dates is not guaranteed to always be exactly 336 hours, even in UTC. If there is a leap second, it would be 335:59:59 hours between the two dates, possibly unbeknownst to the person setting up the voting widget. Someone wanting to invalidate the vote (or whatever the penalty is), could then do so and be within their rights. > > > 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. Right, but who is doing the doubting? There isn't a defined arbiter, thus it can be a battle of the wills: someone on the list claiming it is a significant change vs. (potentially multiple) authors who disagree. Someone needs to be able to say "this is significant" and make that decision binding. > > > 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. Interesting. It's probably fine then. I just wanted to point out that there could be unforseen consequences with people rushing to get to a vote before that period, resulting in less quality RFCs vs. waiting. > > > 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. It said that an RFC timing is bound to a thread starting with a specific subject. Both authors could create two separate threads, one that is "unofficial" but looks official, and the other "official" thread that no conversation happens on. Since no conversation has occurred on the "official" thread, they could just start a vote after two weeks and technically not violate the rules (assuming they made no significant changes to the RFC). We see this often where the pre-discussion thread outlives the official announcement thread, for example; and they're not even being malicious. In this case, the RFC author wouldn't be bound by the cooloff periods at all. > > > 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. Vote starts are based on a specific time, usually with the local time of the email in the headers. It doesn't explicitely and unambiguously say these are durations in a specific timezone, but implies it. One extreme example would be to say that 2 days had passed somewhere in the universe with a different flow of time relative to our local space. > > > 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 — Rob
