On Wed, Feb 6, 2019 at 10:50 AM Nikita Popov <nikita....@gmail.com> wrote:
> More importantly, while our past RFCs in the area of "packaging" have not > been particularly major, that's isn't a property inherent to the category. > For example, a proposal to introduce regular LTS releases, or to make other > major changes to our release scheduling, should certainly be subject to a > 2/3 majority. In each category (whether it's changes to PHP or the release > process) there will always be more and less significant RFCs, and it's hard > to draw a good line between them (we failed spectacularly trying to due > that with "language changes"). I think it is better to err on the side of > being conservative and require a 2/3 majority for everything, especially as > it also obviates any arguments as to what requires or doesn't require a > certain majority. 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. 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. In addition, rushing this RFC for a vote while the discussion of the more comprehensive approach is in motion is quite questionable in my opinion. Zeev >
