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
