Hi
Am 2025-10-09 19:54, schrieb Ilija Tovilo:
Quite late with my response, but I went through the changes again. I
already commented on the PR, but let me do it officially as well.
Thank you.
Prior to starting a vote, RFC authors MUST post an Intent to Vote
message to the discussion thread. The post MUST be made at least 2
days and no more than 7 days before the vote is officially opened
(“Intent to Vote lifetime”).
I feel like the upper bound is a bit low. Effectively, the "intent to
vote" message is an invitation to reread the RFC and provide more
feedback. Complex proposals may want to give people sufficient time to
work through the document, for which 7 days may be on the lower side.
Of course, this is still possible by repeating the intent to vote
message, but it seems a bit odd that this is necessary by following
the proper procedure. Not a major issue though.
If the “Intent to Vote” causes the discussion to restart in a
significant fashion, then IMO the RFC was not actually ready to go to
voting yet. Expiring the Intent to Vote and requiring a new one after
the new discussion is resolved is the intended behavior. Historically in
most cases the Intent to Vote was already “I think I'm done, I plan to
start the RFC in 2 days” and then that either happens, folks provide
feedback or they at least say “Please give me another day or two, super
busy right now”. So I don't expect the 7-day limit to become relevant in
practice.
After the voting period has started, including after the vote closed
and the RFC is either accepted or declined, there MUST NOT be any
further Major or Minor changes to the RFC text and making editorial
changes SHOULD be avoided for the avoidance of doubt.
The property hooks RFC had ~50 examples and we found at least a
handful of mistakes only after the RFC was accepted. I don't think
this is a rare occurrence. Given examples are frequently shared as a
single source of truth, IMO it should be acceptable to fix mistakes
iff they are not directly related to the described semantics. I.e. if
some mistake obviously contradicts the vast majority of the document,
it should be ok to fix it.
If it's *obviously* contradicting, I would consider it a typo fix. If
it's not obvious, folks that only read the examples (which I expect to
be a significant amount, since examples are much more approachable)
might be misled and might want to change their vote as a result of that.
Thus this type of fixes to the examples should not just happen casually.
As an example, during my review of the current PFA RFC, I found several
examples that contradicted my understanding of the “prose semantics”. In
some cases the example was incorrect, but in other cases the “prose” was
incorrect or unclear and the example correctly showcased what was
intended to be proposed. It's thus not easy to say that the prose is
authoritative.
The voting period MAY be canceled within the first 2 days in case of
severe issues with the RFC.
I don't think this restriction is necessary. Tim mentioned to me
off-list it was motivated by this message:
https://externals.io/message/128594#128724. If the vote is passing and
a bigger issue is discovered, allowing the authors to retract the vote
seems like the better approach than relying on voters to change their
vote, especially if there's not enough time for a follow-up RFC. If
the vote is failing, keeping it going only wastes time when a solution
could already be discussed. The linked message says:
Had this policy existed, taking what feedback I had already gotten, I
could have simply declared “an issue” and updated it with their
feedback; restarting the vote.
But I don't think this is true. Any fix for an issue would be
classified as a major change, thus requiring a minimum cooldown period
of 2 weeks. This seems equivalent to creating a new RFC and putting
that to a vote after 2 weeks, which FWIU remains possible.
Does anyone except Ilija have an opinion on this?
Regarding the errata section: If the original text or examples may not
be altered, it would be useful to at least allow adding info boxes to
examples whose semantics have changed (for the same reason as
mentioned above, examples are frequently the only thing people pay
attention to).
That makes sense to me. I don't think the proposed policy text disallows
this, but I'll look if I can spell it out more explicitly that this is
encouraged.
Best regards
Tim Düsterhus
