Counterargument to Deprecate Short Tags RFC V2

• Date: 2019-08-06
• Author: Zeev Suraski, zeev@php.net

An unprecedented proposal has been made with the stated goal of "Preventing Disruptions" to internals conversations. It liberally defines what 'disruptions' are, although it clearly states that other types of behaviors may be considered disruptions if the relevant powers consider them as such. It goes on to deliver far-reaching consequences for those who are found guilty of 'disruption', all the way down to banning people from the project altogether (with an unexplained process for 'redeeming' themselves after a 6 to 12 months).

This is a bad and illegitimate proposal that does nothing but to stir controversy, instill negative vibes, attempt to silence dissenting voices and provide a tool for a majority to oppress the minority. It is tailored to silence specific individuals and the group of people they represent. It also puts one of the people most guilty of violating the letter and spirit of the Mailing List Rules as a supposedly impartial contact point for implementing this new draconian rule of law - which would have been amusing if it wasn't sad.

PHP is an Open Source project that exists since the mid 1990's, and towards the early 2000's has grown to become one of the most popular programming languages in the world. Historically and to this date - decisions about the project's direction have been discussed and made on internals. Intentionally, no limits were ever placed on what's allowed on internals. Honest mistakes - such as end users asking off-topic non-internals-related questions - were typically handled by simply pointing people at the right direction. Foul language - while not very common - was typically handled by pointing it out to the offender - which a lot more often than not solved the problem. However - on topic discussions were never, ever limited - forming opinions and taking decisions through discussion and debate was always the DNA of the internals@ mailing list, with the goal being providing the best possible service for our end users.

While defining 'undesired behaviors' is often a gateway to a wide range of problems, this specific proposal isn't just opening a door to being abused - it is inherently abusive. It defines perfectly legitimate, on-topic discussions as 'disruptive', places an arbitrary group of people who are not necessarily impartial to be pseudo-judges, and intentionally places no limits on what may constitute as 'disruptive behavior' in the future, and turns the voting base - whose mandate is to discuss and decide about future versions of PHP - into a tribunal, where tyranny of the majority is a possible and even likely outcome.

The first explicitly included undesired behavior is “Sending many more emails than other contributors”. In other words, participants would be artificially barred from providing on-topic responses to on-topic feedback. As was evident in several recent discussions (namely - the short tags discussion, the deprecate-undeclared-variable-access discussion, and even the slightly older hebrev() discussion) - there are situations where there are only a handful of people who actively represent a certain position - and they have to do so while conversing with a disproportional amount of people representing the opposing position.

Taking one specific example - there were a lot more people who actively in favor of the deprecation of short tags - and barely a handful of folks who campaigned against it. Still - this did not represent the population at large - and the RFC eventually failed to clear a 2/3 majority. Since a virtually identical RFC managed to clear a 2/3 majority a few weeks earlier (it had to be revoted on due to some issues in the original RFC) - it's fair to say that the

Unpleasant does not mean disruptive

Some of the recent discussions on internals have been extremely unpleasant - there are few if any folks that would disagree with that. However, since our job at internals is to develop and maintain the PHP language for millions of other developers (estimations are rough, but they are between 5 and 10 million worldwide) - the most important criteria for whether a discussion was successful - is whether it allowed people to thoroughly think about the implications and consequences of the proposal, and act accordingly. Perhaps the clearest case where we can measure the impact of such (admittedly unpleasant) discussions is the recent short tags discussions. It's rare that we have an opportunity to see - in practice - what the net influence of discussion is on voting patterns - but in this case we have this unique opportunity to compare voting patterns for virtually identical proposals (the 2nd one in fact being clearer and better than the 1st, which included some problems) - the first which included no meaningful discussion

Proposals can be disruptive too 'Disrupting' these proposals - that is - actively opposing them to prevent a negative impact from materializing for end users - may be (read: is) unpleasant - but it's an entirely legitimate course of action that is not only valid - but justified in many cases.

Our most sacred commitment is to end users - not just or even primarily internals contributors

“The RFC process is what we have”

The proposal is unlimited in scope and casually phrased