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 are 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 very little discussion - and the second which included a fairly intense one.

The first RFC narrowly cleared the 2/3 bar at 67.8%. Slightly more than twice as many people voted in favor of this RFC vs. against.

The second RFC was rejected at 55% support - which means almost as many people voted against it as people who voted in its favor (including both many who voted in favor of the 1st RFC and changed their mind in the 2nd, as well as voters who didn't vote at all on the 1st and decided to vote on the 2nd). This is despite the fact that it was better all around - it included clearer explanations and fixes for several issues that affected the 1st RFC.

There is just one explanation for this substantial change in voter preference - open discussion. Yes, the discussion was intense. Yes - it was unpleasant. Yes, it had a lot of emails coming from a relatively small number of people. And finally, most importantly, yes - it had substantial influence on people's opinions, which in turn resulted in a substantial net change on the results of the poll.

In a parallel universe where the proposal at hand was binding - this discussion would have likely become grounds for banning some 'offenders', even before the discussion concluded - resulting in different results.

This proposal is not about improving internals@ - it's about eliminating 'pesky' opposition.

Proposals can be disruptive too

Analyzing the recent intense discussions on internals while focusing exclusively on the effect on internals - and paying absolutely no attention to the cause - does not make sense.

'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 very poorly phrased with both intentional and unintentional holes