Re: [RFC] Clarify discussion and voting period rules

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