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