On Sun, Feb 8, 2015 at 3:22 PM, Zeev Suraski <z...@zend.com> wrote: > I'm well aware of it as I wrote that policy. The goal of the policy was to > prevent a situation where a temporary majority can introduce features into > the language that would later on be impossible to reverse. It's not by any > stretch a good mechanism to solve controversial votes, which again, should > ideally be avoided as much as possible. It's just that there isn't a better > mechanism. > I know I'm unfairly paraphrasing you, but it sounds like you are saying that for things that you don't have strong feelings about, then you're fine if the others vote amongst themselves. But for things that matter to you, you want to reserve the right to prevent change. Is there a way to fairly describe what you consider too controversial to vote on?
The problem I see with votes for this type of feature is that you probably have a breakdown of something like: - 10% of people don't want scalar type hints - 20% of people want both, but 50% of them would vote for either weak or strong - 35% of people want strict, but 80% of them are fine with weak - 35% of people want weak, but 80% of them are fine with strong So if a strict-only vote happens first, you get 73% to say yes. If weak-only vote happens first, you get 73% to say yes. (I'm obviously just making up these numbers with no scientific basis, but I think the principle is valid.) The only way to be fair IMO is to hold a vote where you rank those four options (weak, strong, both, neither) and hold an instant run-off vote where the first majority wins. And if 'neither' wins, then agree that the topic cannot be revisited until next major version, so that everybody can rest for 5 years. ;) -- Matthew Leverton -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
