Re: Re: hebrevc() and other 'contentious' 7.4 proposed deprecations

On Tue, Jul 16, 2019 at 7:34 AM G. P. B. <george.banyard@gmail.com> wrote: > On Tue, 16 Jul 2019 at 16:18, Zeev Suraski <zeev@php.net> wrote: > Secondly the word you are looking for here is "unanimity"/"unanimous" as > per the Cambridge dictionary [1]: > >> *If a group of people are unanimous, they all agree about one particular >> matter or vote the same way, and if a decision or judgment is unanimous, it >> is formed or supported by everyone in a group* > > > As consensus means, also from the Cambridge dictionary [2]: > >> *a generally accepted opinion or decision among a group of people* >> > > Now unanimity implies consensus however not having a unanimous vote does > not mean there is no consensus. > Moreover, even though "consensus" does come from the Latin *cōnsēnsus* > (“agreement, > accordance, unanimity”) [3] it does not require unanimity IMHO. > While there are different definitions for consensus - as you point out yourself, one of the definitions is certainly a synonym for uninamity - and that's how I personally found it commonly used throughout my life. Regardless, it certainly implies no strong disagreement from those in the minority - which is not the case here. > The RFC process establishes a consensus when 2/3 of the voters agree, > which is currently the case. > As the author of that RFC, I can tell you with complete confidence that deprecations were not in the intended scope of that process. It's quite evident from the language of the Voting RFC itself: "Given that changes to languages (as opposed to changes to apps or even frameworks) are for the most part irreversible - the purpose of the vote is to ensure that there's strong support for the proposed feature." If the bar to remove a feature is identical to introducing it - it's hardly irreversible. The current behavior was never ever intended. It wasn't even supposed to be used for deprecations - but for new features. An argument could be made that this isn't a large enough consensus - > something I don't agree with - however, at the time of writing this, all > the deprecations even pass a 3/4 consensus [4]. > I think there are at least two issues that in a healthy environment would be needed: - A clear, tangible benefit to the deprecation. Having another way of doing something certainly does not constitute a clear, tangible benefit to removing a feature. This should be a pre-requisite for a deprecation. In the past it was an obvious, implicit requirement - but that's from the days where we weren't as 'litigative', so it may make sense to explicitly point it out for the future. - A much stronger consensus, that prevents the tyranny of the majority in such cases. Whether it should be 100% or 95% - but it certainly shouldn't be 2/3 or even 3/4 - and should put into affect the notion that 'changes to the language are for the most part irreversible' - which was a fundamental tenet of the Voting RFC. Zeev