hebrevc() and other 'contentious' 7.4 proposed deprecations

  106206
July 10, 2019 21:33 vsuraski@gmail.com
Two separate topics on this message:

 

First - I wanted to point out that my fierce defense of the hebrev()
function does not in fact extend to hebrevc().  As much as I think the RFC
was really wrong about hebrev(), and we got scarily close to deprecating a
functionality that - while somewhat esoteric - can be extremely useful and
cannot be easily replicated in any way - I have to say that I think the RFC
is pretty much correct on hebrevc().  I don't think it's very plausible
hebrevc() is still in use today - and even if we're missing something and it
is - it can be implemented in a one liner with 100.00% compatibility.  While
I don't think it brings much value to deprecate it - perhaps sending the
message that you shouldn't be using it for HTML bears some level of value.
I voted in favor.

 

Now, with that said - I would really encourage everyone who voted on this
RFC (as well as ones who haven't) to take a look at what I would call the
'contentious votes' in there.  In a nutshell, votes with a substantial
amount of people voting against the deprecation.  If you voted 'yes' for one
of these - please consider, for a moment, whether your position on it is
"It's evil, I really think we're better off without it" or whether it's more
of a "I don't think it's very useful".   If it's the former - by all means,
keep your vote.  But if it's the latter - please consider the possibility
that the fact that a substantial number of people feel strongly enough about
keeping it to vote against the deprecation (and let's admit it - against the
odds), may mean it is, in fact, useful - even if you don't find it useful
yourself.

 

While we can argue whether consensus-based voting makes sense for votes in
general, I think it's tenfold more important when dealing with deprecations.
If there's a substantial minority that thinks a feature is still useful - we
should keep it - unless there's a real tangible cost associated with keeping
it.  For most of the proposed deprecations - that cost is simply not there.

 

For reference, this is what consensus looks like:

https://www.dropbox.com/s/asfgt98rss3xyw2/consensus.PNG?dl=0

https://www.dropbox.com/s/iia7ua4xh6bihe3/consensus2.PNG?dl=0

 

And this is what it doesn't look like:

https://www.dropbox.com/s/56jdl2v1lpxba49/no-consensus.PNG?dl=0

https://www.dropbox.com/s/hj8jozuun7a4w42/no-consensus2.PNG?dl=0

 

To connect with the first point - the hebrevc() vote certainly looks a lot
more like the latter than the former, but I do believe it's mostly related
to confusion with hebrev() and as the author of both - I feel comfortable
supporting its removal :)

 

Thanks for your consideration,

 

Zeev
  106219
July 16, 2019 14:18 zeev@php.net (Zeev Suraski)
Given apparently nobody has paid any attention to this email (both in terms
of my support of deprecating hebrevc(), and my request to reconsider
supporting proposals with substantial numbers of 'nay' voters) - I'm
resending it one more time for consideration:

On Wed, Jul 10, 2019 at 2:33 PM <zeev@php.net> wrote:

> Two separate topics on this message: > > > > First – I wanted to point out that my fierce defense of the hebrev() > function does not in fact extend to hebrevc(). As much as I think the RFC > was really wrong about hebrev(), and we got scarily close to deprecating a > functionality that – while somewhat esoteric – can be extremely useful > and cannot be easily replicated in any way – I have to say that I think > the RFC is pretty much correct on hebrevc(). I don't think it's very > plausible hebrevc() is still in use today – and even if we're missing > something and it is – it can be implemented in a one liner with 100.00% > compatibility. While I don't think it brings much value to deprecate it – > perhaps sending the message that you shouldn't be using it for HTML bears > *some* level of value. I voted in favor. > > > > Now, with that said – I would *really* encourage everyone who voted on > this RFC (as well as ones who haven't) to take a look at what I would call > the 'contentious votes' in there. In a nutshell, votes with a substantial > amount of people voting against the deprecation. If you voted 'yes' for > one of these – please consider, for a moment, whether your position on it > is "It's evil, I really think we're better off without it" or whether it's > more of a "I don't think it's very useful". If it's the former – by all > means, keep your vote. But if it's the latter – please consider the > possibility that the fact that a substantial number of people feel strongly > enough about keeping it to vote against the deprecation (and let's admit it > – against the odds), may mean it is, in fact, useful – even if you don't > find it useful yourself. > > > > While we can argue whether consensus-based voting makes sense for votes in > general, I think it's tenfold more important when dealing with > deprecations. If there's a substantial minority that thinks a feature is > still useful – we should keep it – unless there's a real tangible cost > associated with keeping it. For most of the proposed deprecations – that > cost is simply not there. > > > > For reference, this is what consensus looks like: > > https://www.dropbox.com/s/asfgt98rss3xyw2/consensus.PNG?dl=0 > > https://www.dropbox.com/s/iia7ua4xh6bihe3/consensus2.PNG?dl=0 > > > > And this is what it doesn't look like: > > https://www.dropbox.com/s/56jdl2v1lpxba49/no-consensus.PNG?dl=0 > > https://www.dropbox.com/s/hj8jozuun7a4w42/no-consensus2.PNG?dl=0 > > > > To connect with the first point – the hebrevc() vote certainly looks a > lot more like the latter than the former, but I do believe it's mostly > related to confusion with hebrev() and as the author of both – I feel > comfortable supporting its removal :) > > > > Thanks for your consideration, > > > > Zeev >
  106220
July 16, 2019 14:34 george.banyard@gmail.com ("G. P. B.")
On Tue, 16 Jul 2019 at 16:18, Zeev Suraski <zeev@php.net> wrote:

> Given apparently nobody has paid any attention to this email (both in terms > of my support of deprecating hebrevc(), and my request to reconsider > supporting proposals with substantial numbers of 'nay' voters) - I'm > resending it one more time for consideration: > > On Wed, Jul 10, 2019 at 2:33 PM <zeev@php.net> wrote: > > > Two separate topics on this message: > > > > > > > > First – I wanted to point out that my fierce defense of the hebrev() > > function does not in fact extend to hebrevc(). As much as I think the > RFC > > was really wrong about hebrev(), and we got scarily close to deprecating > a > > functionality that – while somewhat esoteric – can be extremely useful > > and cannot be easily replicated in any way – I have to say that I think > > the RFC is pretty much correct on hebrevc(). I don't think it's very > > plausible hebrevc() is still in use today – and even if we're missing > > something and it is – it can be implemented in a one liner with 100.00% > > compatibility. While I don't think it brings much value to deprecate it > – > > perhaps sending the message that you shouldn't be using it for HTML bears > > *some* level of value. I voted in favor. > > > > > > > > Now, with that said – I would *really* encourage everyone who voted on > > this RFC (as well as ones who haven't) to take a look at what I would > call > > the 'contentious votes' in there. In a nutshell, votes with a > substantial > > amount of people voting against the deprecation. If you voted 'yes' for > > one of these – please consider, for a moment, whether your position on it > > is "It's evil, I really think we're better off without it" or whether > it's > > more of a "I don't think it's very useful". If it's the former – by all > > means, keep your vote. But if it's the latter – please consider the > > possibility that the fact that a substantial number of people feel > strongly > > enough about keeping it to vote against the deprecation (and let's admit > it > > – against the odds), may mean it is, in fact, useful – even if you don't > > find it useful yourself. > > > > > > > > While we can argue whether consensus-based voting makes sense for votes > in > > general, I think it's tenfold more important when dealing with > > deprecations. If there's a substantial minority that thinks a feature is > > still useful – we should keep it – unless there's a real tangible cost > > associated with keeping it. For most of the proposed deprecations – that > > cost is simply not there. > > > > > > > > For reference, this is what consensus looks like: > > > > https://www.dropbox.com/s/asfgt98rss3xyw2/consensus.PNG?dl=0 > > > > https://www.dropbox.com/s/iia7ua4xh6bihe3/consensus2.PNG?dl=0 > > > > > > > > And this is what it doesn't look like: > > > > https://www.dropbox.com/s/56jdl2v1lpxba49/no-consensus.PNG?dl=0 > > > > https://www.dropbox.com/s/hj8jozuun7a4w42/no-consensus2.PNG?dl=0 > > > > > > > > To connect with the first point – the hebrevc() vote certainly looks a > > lot more like the latter than the former, but I do believe it's mostly > > related to confusion with hebrev() and as the author of both – I feel > > comfortable supporting its removal :) > > > > > > > > Thanks for your consideration, > > > > > > > > Zeev > > >
Hello Zeev, First of all it seems that you've mixed up your consensus2 and no-consesus2 files as they currently show the opposite of what you want to convey, I think. 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. The RFC process establishes a consensus when 2/3 of the voters agree, which is currently the case. 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]. Best regards George P. Banyard [1] https://dictionary.cambridge.org/dictionary/english/unanimous [2] https://dictionary.cambridge.org/dictionary/english/consensus [3] https://en.wiktionary.org/wiki/consensus [4] https://php-rfc-watch.beberlei.de/
  106221
July 16, 2019 15:00 zeev@php.net (Zeev Suraski)
On Tue, Jul 16, 2019 at 7:34 AM G. P. B. 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
  106222
July 16, 2019 16:06 george.banyard@gmail.com ("G. P. B.")
On Tue, 16 Jul 2019 at 17:00, Zeev Suraski <zeev@php.net> wrote:

> On Tue, Jul 16, 2019 at 7:34 AM G. P. B. banyard@gmail.com> wrote: > >> 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. >
It seems this mention has been removed after the amendment from the "Abolish Narrow Margin" RFC, and I'm also seeing that there hasn't been any amendment made to the document after the "Abolish Short Votes" RFC passed". I personally don't see the problem of having deprecation with the same threshold as feature for voting, which is only mandatory since the Narrow Margin RFC came into effect, but this is only my opinion. If you feel that strong about correcting this issue you could make an RFC to amend the Voting RFC/Process, like Joe did (twice), to add a special case for feature deprecation. And no I don't think the voting process need a complete revamp. Also, I just want to point out that, IMHO, the main reason for the high amount of deprecations for PHP 7.4 is that it is the last minor version before the next major. And who know how long it is going to take to have the next major (supposedly 5 years) which is a long time in tech.
> 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. >
This ties in to the point above about making an amendment to the Voting process.
> - 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 >
These thresholds are, in my mind, pure insanity. Let's run some numbers on how little people do you need to make a vote fail with 95% (because 100% is always 1): 10 voters: 1 person (need 9.5 voters in favour), 15 voters: 1 person (need 14.25 voters in favour) , 20 voters: 2 people (need 19 voters in favour) , 25 voters: 2 people (need 23.75 voters in favour) , 30 voters: 2 people (need 28.5 voters in favour, which is usually how many people vote for "normal" RFC from what I see 35 voters: 2 people (need 33.25 voters in favour) 40 voters: 3 people (need 38 voters in favour) about the number of people currently voting on the PHP 7.4 deprecations RFC 45 voters: 3 people (need 42.75 voters in favour) 50 voters: 3 people (need 47.5 voters in favour) 55 voters: 3 people (need 52.25 voters in favour) high profile RFCs 60 voters: 4 people (need 57 voters in favour) 65 voters: 4 people (need 61.75 voters in favour) 70 voters: 4 people (need 66.5 voters in favour) Typed property V2 RFC (super high profile RFC) 75 voters: 4 people (need 71.25 voters in favour) 80 voters: 5 people (need 76 voters in favour) This is madness: to make a vote fail you just need to find, with current voting turnout, 2 other people to make a vote fail. Sure it is possible for a tyranny of the majority but with these threshold there is also clearly a tyranny of a minority because 56 voters in favour and 3 against is IMHO a clear statement of consensus but would fail with a 95% majority. And I don't think a 90% threshold is that much better. I think the highest threshold I would possibly go with high discomfort is 80% (4/5). I know that you're aren't necessarily keen on having so many people able to vote, which is the opposite of what I believe as I think the more people vote the better and more reflective of a vote we get. That's why we are always going to end in disagreement about these things IMO as we have opposite philosophies. Side note: I replied to you resending this email is to let you know that at least *someone* has read it -even before the resend - however I don't think I'm the only one who's read it and didn't reply. Best regards George P. Banyard