That is https://news-web.php.net/php.internals ?

Since the update to include the full threading view, https://news-web.php.net/php.internals would be the preferred link. But I would also be good with externals, since the IDs match up and folks are able to use either one. What's important to me is that folks are able to easily find the discussion.

IMO, the upper bound (at least such a low one) is pretty unnecessary. As long as nothing has changed, internals have effectively already soft-approved the vote by not objecting.

I think the “Intent to Vote” becomes meaningless if folks don't follow up on it. To me it's not just a “last call for change requests”, but also moving the RFC discussion to the top of the INBOX to make it easier for folks to find it when the vote actually happens and as a clear communication that the RFC authors consider the RFC finished. It would be odd for them to leave the RFC sitting around for another month before then actually starting the vote.

Saying "I'll start the vote soon", and doing so in 10 days doesn't seem problematic to me, especially for very complex and drawn-out RFCs. Actually, 2 days may not even be enough for people to have the time to re-read large RFCs. Given that's effectively the aim of this reminder, it might make sense to be a bit more lenient.

Edit: Okay, we should use the upper bound for this argument, i.e. the 7 days. But for very complex RFCs, 7 days may still not be enough for peopel with busy schedules.

What about mistakes in the examples? I think we fixed some examples months after RFCs have been accepted. Keeping the mistakes would be confusing. Obviously, this assumed no malicious intent (e.g. fixing obvious mistakes, not tweaking semantics or sneaking in new features).

Edit: I see this is referring only to the voting period, whereas I interpreted it as "from then on". Maybe adjust to "during the voting period"? Still doesn't explain what should happen if a mistake is spotted in an example during the vote.

Edit 2: Nevermind. It says "including after the vote closed and the RFC is either accepted or declined", which I overlooked on my second read. This seems to be in conflict with the errata section.

This seems to be in conflict with the errata section.

The errata section is intended “append-only”. The RFC remains as a record of what was being voted on and the errata section explains why that didn't happen.

Still doesn't explain what should happen if a mistake is spotted in an example during the vote.

If it's an obvious mistake it falls under the typo rule. If the example is actively misleading with regard to semantics, this might have an impact on the vote (folks might vote differently had the example been differently). In that case, this should be resolved as any other mistake with significance (e.g. by prominently mentioning it on the list and if necessary canceling the vote).

The errata section is intended “append-only”. The RFC remains as a record of what was being voted on and the errata section explains why that didn't happen.

I still don't find this good, because frequently people look only at examples and expect them to be correct.

If it's an obvious mistake it falls under the typo rule.

Reality is a bit more nuanced. Sometimes there are semantic mistakes, but maybe not the ones that the example is highlighting. I don't think such an example should be grounds for invalidating a vote, when the semantics are sufficiently clarified in the RFC text and other examples.

In that case, this should be resolved as any other mistake with significance (e.g. by prominently mentioning it on the list and if necessary canceling the vote).

As mentioned, this also happens for RFCs that have long passed and even been merged.

What's the rationale of restricting the cancling of the vote to the first two days? If somebody were to point out a major problem later in the voting period, wouldn't it make sense for the authors to invalidate the vote and solve the issue, rather than the RFC being accepted in a flawed state? Of course, they could still choose to simply not merge it, and create a follow up RFC that solves the issue, but then there's no clear path forward if that second vote fails.

see https://externals.io/message/128594#128724: This is to prevent folks from canceling the vote at 13 days and 23 hours if they are unhappy with the results. At a certain point it's better to just let the vote run its course.

In case of “honest mistakes” with the RFC, I expect follow-up RFCs to be well-received by the community. And if there's an obvious solution to the mistake, this can also be solved by “simple agreement” using the Errata mechanism.

The RFC is intentionally voting on a specific commit hash to clearly link RFC and PR. For the avoidance of doubt, I'm therefore not even fixing typos at this point.

Can you please send them as a separate follow-up PR if / when the RFC gets accepted and this PR merged?