Analysis of 'Preventing Disruptions of Conversations' proposal

• 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 is a potent combination of laconic text, vague definitions, draconian consequences, extreme bias, and bad will. It's hard to overstate the potential risk associated with enacting such rules hastily - both in the short term, and even more so down the road.

In addition - this proposal radically misuses the RFC process, which was never designed to regulate the most fundamental communications channels (which created it in the first place as a means to an end, and predates it by almost 15 years) and silence dissenting voices, and as such, has no legitimacy and cannot be binding.

Independent of its fundamentally flawed use of the Voting RFC, the proposal contains countless holes and risks. The purpose of this analysis is to shed some light on them, independently of claiming that it is entirely illegitimate.

PHP is an Open Source project that exists since the mid 1990's. Towards the early 2000's, it 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@ - a mailing list that is open to everyone for both passive and active participation.

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. Over the past 20+ years, we've banned less than a handful of people - and these extreme cases were exclusively in case of repeated, off-topic, foul-language behavior - with universal support and no objections from virtually any other member of internals@.

It's difficult to find where to start.

It's purposely leaves out clear definitions of what constitutes 'disruptive behavior'

Quoting the text: “However other behaviours that people find disruptive, that someone refused to stop doing when asked to using the process listed below, would also be covered by this RFC.”

This is a purposely open-ended definition, that is a perfect gateway for a future slippery slope towards misusing the mechanism.

Defines 'disruptive behaviors in an extremely opinionated way

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 in on-topic feedback - simply because their email count is supposedly too high. As was evident in several recent discussions - 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. This means that these folks would have likely cleared the “send many more emails than other contributors” laconic definition, and be subject for abuse by this proposal.

Placing artificial limits on the number of responses allowed will have an affect on the outcome of decisions, and as such, is inherently illegitimate and flawed.

The second example - “Repeatedly telling other contributors that they are not allowed to discuss otherwise on-topic issues” is funny in many ways, as it basically is the very definition of this RFC - telling other contributors what on-topic subjects they are or not allowed to discuss. It also conflates a legitimate (and correct) position - that the RFC process wasn't designed to handle any and all decisions in PHP - with telling people they're not allowed to discuss something.

Everybody should be allowed to discuss anything that's on-topic on internals@ with no limits. It does not mean that anything and everything can be put to a 2/3 vote. Note: Just because anything on-topic can be discussed on internals@, doesn't mean it's always a good idea; More on that below.

The third and last example - “Repeatedly asking people to hold off on proposing an RFC” - does, in effect, encourage disruption. There's no doubt that had the above-mentioned discussions (deprecation of short tags, deprecation of undeclared variables, and heck - even hebrev()) never taken place - the atmosphere of internals@ would not have suffered a blow. Even though the proposal seeks to solve this by artificially taming discussion and implementing a tyranny of the majority - the best (and only) way to avoid these contentious discussions would have been to not follow through with them as-is when it became clear they were contentious.

Pointing out that a given RFC is contentious and asking an author to reconsider it is perfectly legitimate, and may actually help out reducing contentious discussions on internals@ (as opposed to finding ways to artificially suppress them). In fact, the RFC HOWTO itself recommends that people measure the reaction to their proposal prior to going through with it:

Email internals@lists.php.net to measure reaction to your intended proposal.

Unpleasant does not mean disruptive

Some of the recent discussions on internals have been extremely unpleasant - that's one of the few facts over which there's likely wall to wall consensus. However, the fact they were unpleasant does not mean they were conducted in a disruptive way.

Our job at internals@ is to develop and maintain the PHP language for millions of other developers. With estimations ranging between 5 and 10 million developers 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 - not whether it was pleasant or not.

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 the 2nd RFC 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 other words - it was productive (assuming it was impossible to entirely prevent that discussion from ever taking place, which would have been a lot more productive).

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 - likely resulting in different results.

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

Proposals can be disruptive too

As already alluded to above, analyzing the recent intense discussions on internals, focusing exclusively on the effect while paying absolutely no attention to the cause - does not make sense.

In recent months, we've been dealing with a steady stream of contentious, polarizing RFCs. Placing arbitrary limits on discussion, while at the same time doubling down on the “everything is up for a 2/3 vote” is not only dishonest - it's a recipe for disaster.

Instead of repeatedly bringing up contentious RFCs for discussion, and then finding ways to silence the opposition - we should be spending our cycles coming up with productive solutions that work for everyone. Insistence on bringing up contentious proposals - will result in contentious discussion, which are unpleasant, unproductive - and yet, inevitable - the moment such proposals are brought to discussion.

Our most sacred commitment is to end users

Discussions on internals@ have remarkably far reaching effects, influencing millions of people and countless ecosystems. While keeping things calm and relaxed is definitely a worthy goal - it is hardly the primary goal of internals@, and certainly not an exclusive one. In situations where keeping things calm may adversely affect countless users - it's not only OK to debate every aspect of it at length - it's our obligation to do so. The recently discussed topics - most of which would have had tremendous impact on a very large subset of the PHP codebase and userbase worldwide - definitely fall in that category.

“The RFC process is what we have”

A person that joined internals@ only after the RFC process was enacted in 2011 may be excused to believe that the RFC process is all we have, and that it governs every possible aspect of the PHP language. However, that isn't true - and there's ample evidence for that available.

First, there are fundamental principals which date all the way back to the late 1990's, that are apparent to anybody who reads the archives. Some of them were covered above - open unrestricted discussion, and bias for downwards compatibility (which is not the same as never breaking compatibility - but rather, that there should be exceptionally good reasons to do so).

Another, which is just as real, is decision by consensus for critical decisions.

As a principal author of the Voting RFC, and as the person who came up with the 2/3 bar - I can say with absolute confidence that it was not meant to regulate neither transforming policy changes (such as this proposal) nor radical breaks for the language. However, you don't only have to take my word for it - there - 'clues' are available all over the various RFC documents, beginning with the Voting RFC itself:

Given that changes to languages (...) are for the most part irreversible - the purpose of the vote is to ensure that there's strong support for the proposed feature.

(emphasis added)

This quote is also a strong hint towards the fact it was not meant to regulate deprecations - calling new features “irreversible”. In addition, in the RFC template, it states:

Consider only features which have significant traction to a large chunk of our userbase, and not something that could be useful in some extremely specialized edge cases […] Make sure you think about the full context, the huge audience out there, the consequences of making the learning curve steeper with every new feature, and the scope of the goodness that those new features bring.

List the proposed PHP versions that the feature will be included in. Use relative versions such as “next PHP 7.x” or “next PHP 7.x.y”.

(emphasis added)

It's true that since the Voting RFC process was enacted, it was used for minor or tactical policy decisions, as well as some tactical deprecations. However - neither of these imply that it suddenly became as our sole form of governance that can be applied to everything - especially as it attempts to make the jump to cover topics like project participation policies, mailing list censorship, or transformative breaking changes to the language itself. It's also worth pointing out that even in the handful of cases where it was used for minor policy changes - all of these policy changes effectively cleared the bar of decision by consensus, and not just barely clearing a 2/3 bar - which would have implied an extremely controversial decision.

Areas which were never meant to be covered by the Voting RFC - are still not covered by it, and are subject to decision by consensus - precisely as they were prior to 2011.

Forcing contentious emails to be on-list is the very definition of 'disruption'

The proposal is very poorly phrased with both intentional and unintentional holes

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.

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.