> I'll reiterate my main two issues with this RFC: > - I do think that we need 50%+1 votes for certain decisions. Naming the > next version of PHP, or even deciding to release it outside of the yearly > cycle should not require a 2/3 vote. It's not so much erring on the side > of being conservative - it's enforcing a bias for status-quo that simply > doesn't exist in these issues. Is it the end of the world that we won't > have it? No, but it's better that we would. > - More importantly, the voting base issue must be solved before we change > the voting rules. I find it extremely problematic process-wise that we'll > change the rules using a voting base that was never defined to be valid in > the first place.
It's the only definition we currently have. We have to rely on the same voting base to change the voting base. I don't see how voting on all other RFCs is fine, but voting on this one isn't. > You mentioned that you don't see why the two issues are > interlinked - and you may be right, it's more that one is dependent on the > other. Voting eligibility is the first question we should answer, and it > should only be followed by the voting rules themselves. We currently have an answer to voting eligibility. It's one you may not like, but changing that is completely independent of changing voting margins. Regards, Niklas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
