Re: [PHP-DEV] Re: hebrevc() and other 'contentious' 7.4 proposeddeprecations

This is only part of a thread. view whole thread
  106251
July 23, 2019 11:12 johannes@schlueters.de (Johannes =?ISO-8859-1?Q?Schl=FCter?=)
On Tue, 2019-07-16 at 08:00 -0700, Zeev Suraski wrote:
> > 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.
A good reading on consensus in technical discussions is this: https://tools.ietf.org/html/rfc7282 In my view there is a difference between a vote and consensus. In a vote I state "this is my preference" in a consensus I can say "it is not my preference, but I can support it" And I believe the key is to identify whether there are objections/vetos. Those have to be respected, as voting over volunteer contributors drives them away. Voting is good if there is no clear consensus or if one has to make a decision, left or right, and there's no clear consensus. Unanimity in a vote means that this is the preferred approach for everybody (among voters) On hebrev()/hebrevc(): I believe most contributors have no idea what it does and I for one have no need. It doesn't hurt me, though. As long as it works for the users I'd keep it since cost is low. If I'd support adding such a function in future is a different question. johannes
  106291
July 25, 2019 12:23 rowan.collins@gmail.com (Rowan Collins)
On Tue, 23 Jul 2019 at 12:12, Johannes Schlüter <johannes@schlueters.de>
wrote:

> A good reading on consensus in technical discussions is this: > https://tools.ietf.org/html/rfc7282
I just skimmed that document, and I think there's a lot we could learn from it, if we had the confidence to truly reform. You could pretty much replace "IETF" with "PHP" in this paragraph, and you'd have a summary of why we *shouldn't* rely on votes as much as we do:
> We don't vote in the IETF. In some ways, we can't vote: Since the > IETF is not a membership organization, it's nearly impossible to > figure out who would get a vote for any given question. We can't > know who the "members" of any given working group would be at any one > time, and we certainly can't know who all of the "members" of the > IETF would be: That's why we refer to "participants" in the IETF; the > IETF doesn't really have "members".
> On hebrev()/hebrevc(): I believe most contributors have no idea what it > does and I for one have no need. It doesn't hurt me, though. As long as > it works for the users I'd keep it since cost is low. If I'd support > adding such a function in future is a different question. >
I agree with everyone who has said removing a feature (and every "deprecation" is actually a proposal to remove something) should have a much higher bar than not adding it. I think there is also an extra requirement that removal (and therefore deprecation) should have, which many of these proposals *also* don't pass: what should people be using instead? To me, every deprecation note should be able to clearly say one of two things: - If you are using this feature, You Are Wrong. Don't do it, emulate it only as a short-term measure, work to remove it. - If you are using this feature, you should use this specific feature instead, because it is better in these ways. Take convert_cyr_string, for example. The RFC says "one of mb_convert_encoding(), iconv() or UConverter may be used for this purpose". There's a sleight of hand here - it sounds like we've offered the user an upgrade path, but we haven't actually said *how* to get the equivalent functionality. Why are there three options, all in different optional extensions? Will one of them be removed in a few years' time, leaving users to fix their code all over again? What options does each of these need to emulate the old function? Is it even possible, or will there be subtle differences that need testing? If the aim is to have a Right Way to do everything, we should be saying what that Right Way is. I picked this example in particular, because I'd actually love there to be better guidance on how to convert encodings, and I'd like to remove utf8_encode and utf8_decode, which I think cause far more damage by being so badly named. I haven't proposed it, because for the people who are using those functions correctly, there would need to be a clear replacement, and right now there isn't. Regards, -- Rowan Collins [IMSoP]