| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| rfc:counterargument:prevent_disruptions_of_conversations [2019/09/24 18:24] – WIP zeev | rfc:counterargument:prevent_disruptions_of_conversations [2019/09/26 10:47] (current) – WIP zeev |
|---|
| ====== Analysis of 'Preventing Disruptions of Conversations' proposal ====== | ====== Analysis of 'Preventing Disruptions of Conversations' proposal ====== |
| * Date: 2019-08-06 | * Date: 2019-09-26 |
| * Author: Zeev Suraski, zeev@php.net | * Author: Zeev Suraski, zeev@php.net |
| |
| 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. | 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, 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. | 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 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. | 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. |
| |
| 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. | Its fundamentally flawed use of the Voting RFC aside, the proposal contains countless bad ideas, holes and risks. The purpose of this analysis is to shed some light on them. |
| |
| |
| 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. | 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@. | 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 ==== | ==== Why this proposal is bad ==== |
| |
| It's difficult to find where to start. | 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'** | ===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." | 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." |
| |
| |
| **Defines 'disruptive behaviors in an extremely opinionated way** | ===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. | 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. | 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. | 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. | 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. | 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 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: | 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> | <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. |
| |
| **Unpleasant does not mean disruptive** | ===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. | 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. |
| 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. | 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). | 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. | 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. |
| |
| |
| **Proposals can be disruptive too** | ===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. | 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. | 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 discussion, which are unpleasant, unproductive - and yet, inevitable - the moment such proposals are brought to discussion. | 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** | ===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. | 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"** | ==="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. | 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). | 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. | 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: | 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) | <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) |
| |
| 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: | 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>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> |
| |
| |
| 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. | 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 jump to cover topics like project participation policies and mailing list censorship. 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 (our bar for radical and far-reaching-consequence decisions such as this), 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'** | ===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]] |
| |
| **The proposal is very poorly phrased with both intentional and unintentional holes** | |
| |
| | ===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. |
| |
| |
| 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). | ====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. |
| |
| 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. | |
| |