On Tue, 23 Jul 2019 at 12:12, Johannes Schlüter <johan...@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]
