On Wed, Sep 24, 2025, at 09:09, Tim Düsterhus wrote: > Hi > > Am 2025-09-19 10:55, schrieb Tim Düsterhus: > >> Please find the RFC at: > >> https://wiki.php.net/rfc/rfc_discussion_and_vote > >> And the PR at: https://github.com/php/policies/pull/23 > > > > If you followed along the discussion, you might've seen that Larry > > offered to improve the phrasing of the policy for clarity. This has > > happened now and I think Larry did a great job at improving the > > structure of the policy text, while still using precise language and > > preserving the intended semantics. He made some changes to the policy > > as part of the rephrasing and I agree with them all. Specifically: > > I just realized that the RFC text was not strictly following the latest > policy in the PR, the explanation of the voting widget was missing (“All > voting widgets on the RFC MUST include all relevant details for that > vote, as described in the "Required Majority" section below”). I have > just added that (“Primary Vote requiring a 2/3 majority to accept the > RFC:”) and will also make sure to include that in the RFC template, > should this RFC be accepted. > > I'm treating this change to the RFC text as a “Minor change”, since it's > basically just clarification. It's implied by the existing policy that > the single voting widget is a primary vote and that it requires a 2/3 > majority. > > All that said, I'm happy to hear some feedback on whether or not the > updated phrasing is looking good to you? :-) > > Best regards > Tim Düsterhus >
Hi Tim, This goes back to what I was saying: pretty much any change can be justified as “a clarification” by an author. We can choose to accept the implication of a 2/3 majority, or challenge it. That being said, I agree with you. But it’s still worth pointing out that this can be abused and there isn’t much recourse. I also noted you changed the text to mention that a vote can basically be restarted for any reason. This would allow an unscrupulous person to basically restart a vote if it isn’t going in the direction they want, without any reason other than an “issue” with the RFC. This means they can rely upon attrition to eventually pass an RFC that would otherwise not pass, bypassing the current “one year or with major changes” rule. For example, the nested classes RFC was clearly not going to pass. 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. I personally wouldn’t do that, but this would explicitly allow that behavior. — Rob
