On Thu, Sep 4, 2025, at 15:48, Tim Düsterhus wrote: > Hi > > Am 2025-09-04 00:07, schrieb Rob Landers: > > I’m still trying to understand the problem this language is solving, > > can you help me out here? It is incredibly precise and detailed, but > > gets into over-specification, IMHO. Traditionally, PHP policy has > > leaned towards principle and illustrative examples over exact > > prescriptions. Is this intended to shift away from that approach? > > The language is trying to solve ambiguity. The current phrasing of the > policy is full of words like “maybe”, “might”, “should”, which leave > room for interpretation. As I have mentioned in my reply to Thomas, a > (formal) policy is intended to to allow cut discussion short in cases of > disagreement by allowing someone to point towards the policy and say: > “The policy we agreed on *clearly* specifies that X, but this rule was > violated. I object with proceeding until this violation is resolved.”. > It should not possible for the other side to “well actually it could > also mean Y”, because they disagree. As an example the current policy > states: > > > There'd be a minimum of 2 weeks between when an RFC that touches the > > language is brought up on this list and when it's voted on is required. > > Other RFCs might use a smaller timeframe, but it should be at least a > > week. > > 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? Somehow I doubt this would actually fly, despite "maybe, technically", being within the rules. > > Further, how will this be enforced? Currently, if I understand > > correctly, this is generally enforced by the CoC and it doesn’t seem > > equipped to deal with "your vote ended 1 hour too early" type > > situations. > > This is a good point that indeed should be written down in some way. I > generally expect everyone to act in good faith, i.e. to only violate the > policy by accident and to immediately remediate any issues once made > aware of the mistake. Violations of the cooldown period should generally > be recognized when pre-announcing the vote and the RFC author should > then acknowledge the violation in a reply, wait a little more and then > pre-announce the vote at a later point. Violations of the > pre-announcement period should be recognized when starting the vote and > the RFC author should then acknowledge the violation, cancel the vote > and restart it after a new pre-announcement (with a new title to clear > out any votes). The Wiki tracks the time of voting, so any votes cast > after the voting period has ended would be ignored (which would only > really matter in cases of close votes). 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? 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. 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). 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. 5. It says that you can't add or change a voting widget, but you can remove them freely without triggering a vote reset. 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. 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? 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"? > > If the RFC author follows through with a vote, despite being in > violation of the rules and being made aware of it, the result of the > vote would be void. I'd say that if no one points out the violation > after a “reasonable period of time” has passed, the violation is > considered to not have occurred (i.e. it should not be possible to void > a vote at day 13 of the voting period). > > Best regards > Tim Düsterhus > 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. 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. My point, hopefully, is that the more specific you are, the more wiggle room people actually have both to attack and defend. At the end of the day, this is a people problem, not a policy problem. It's one thing to clarify, but another to specify. — Rob
