PHP: rfc:analysis:prevent_disruptions_of_conversations

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Analysis of 'Preventing Disruptions of Conversations' proposal ======
  * Date: 2019-09-26
  * Author: Zeev Suraski, zeev@php.net


===== Introduction =====

An unprecedented proposal has been made with the stated goal of [[https://wiki.php.net/rfc/prevent_disruptions_of_conversations|"Preventing Disruptions"]] to internals@ conversations.

It is a potent combination of laconic text, vague definitions and draconian consequences.  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 also radically misuses the RFC process, which was never designed to regulate the most fundamental communications channel (that created it).  While this analysis briefly touches that subject towards the end, its main focus is the countless number of bad ideas, holes and risks that this proposal poses if it became binding.



===== Background ======

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 no objections from virtually any other member of internals@.

The proposal at hand aims to radically change that - by placing both known as well as unknown limits on the conversation dynamics - thereby stifling debate, alongside proposing draconian, poorly regulated and poorly defined punishment processes using the electronic equivalent of summary trials.


==== Why this proposal is bad ====

While this analysis attempts to cover some of the key problems and risks associated with this proposal, it is by no means an exhaustive list.

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

Quoting the text:

<blockquote>"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."</blockquote>

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.  In addition, as some of pointed out during the discussion on internals@ - instead of telling people what they should or shouldn't write, readers have the luxury of both choosing their threads, and choosing whose messages they read.  If they find someone's on-topic feedback on a certain thread to be far-reaching in their view, they always have the option to simply ignore it.

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 example - //**"Repeatedly asking people to hold off on proposing an RFC"**// - does, in effect, encourage disruption.  There's no doubt that if we could wave a magic wand, and magically make some of the recent discussions (deprecation of short tags, removal of undeclared variables, and even hebrev()) never take place - the atmosphere of internals@ would have been better off.  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 [[https://wiki.php.net/rfc/howto|RFC HOWTO]] itself recommends that people measure the reaction to their proposal prior to going through with it:

<blockquote>Email internals@lists.php.net to measure reaction to your intended proposal.</blockquote>

Note that this does not mean that controversial topics must never be discussed.  Everything can be discussed - some of the decisions we reached by consensus started as controversial topics.  It does mean, though, that the value they bring should be proportional to the level of controversy and be worth it - and that the RFC author should be prepared to defend their proposal, if they really believe it's worth it.

Finally, the proposal mentions the crime of //**"Rejecting the results of RFC votes"**//.  As a recent occurrence demonstrated (short tags) - even on-topic RFCs can be (unintentionally) misleading or incompatible with the RFC process.  Although admittedly, it's better to point out such issues prior to the poll being closed - pointing that out and requesting that it is fixed must not become a punishable offense.


===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 arguably 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.  This is the cause - what happened on internals is the effect - not the other way around.  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, often unpleasant discussion (for everyone involved).  The moment controversial proposals are brought to discussion - this is inevitable.


===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.


===Majority Rule is not Democratic without Minority Rights===

While majority rule is a key element of Democratic systems, it is hardly the single requirement.  The rights of minorities are a key aspect of Democratic systems, and this proposal provides an unrestrained mechanism to hurt them - allowing voices to be silenced and people to be banned in contentious, not nearly unanimous decision processes.  A good read on Majority Rule and Minority Rights is [[https://www.annenbergclassroom.org/glossary_term/majority-rule-and-minority-rights/|available here]]


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

Almost by definition, personal emails - which are irrelevant for the list subscribers at large - should not be sent on the list.  They are, by definition, off topic.  This is especially true for ones dealing with negative personal feedback - sending them on list does nothing but increase levels of negative vibes and unnecessary drama.  And yet - the proposal seeks to make these grounds for perpetual banning.  To be clear - it does not seek to define a recurring instance of sending personal negative emails as abuse, but rather, even a single occurrence of a mail that is deemed negative - suffices.  Based on recent experience, it's also very flexible with its definition of the word 'abusive' - which means we don't even have to wait for sliding down the slippery slope - we're already well under way downhill.

'Adversarial' off-topic discussions are best off not happening at all, but if they do happen - it's best that they're super short and taken off list.  There's no need to bug everyone with the drama.


==="The RFC process is [all that] 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.  One of these core tenets was covered above - open unrestricted discussion.

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  meant to regulate feature proposals - and not transforming policy changes - which this proposal certainly falls under.  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:

<blockquote>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**.</blockquote>  (emphasis added)

In addition, in the RFC template, it states:

<blockquote>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.</blockquote>

<blockquote>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”.</blockquote>

(emphasis added)


It's true that since the Voting RFC process was enacted, it was used for limited-scope / tactical policy decisions.  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 giant leap to cover topics like project participation policies, mailing list censorship and full-fledged banning of members.  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.


====Summary====

Unlike the response to recent proposals during recent discussions - which despite being unpleasant - did result in tangible changes to both the proposals themselves as well as the voting patterns - this proposal focuses and enlarges an extremely divisive topic, both in terms of the proposal itself as well as how it seeks to implement it.  Instead of trying to come up with constructive solutions that would do away with much of the contention - this proposal creates a whole new vector for contention, bound to lead to more unnecessary and pointless disruption.
Page Tools
