| Next revision | Previous revision |
| rfc:analysis:prevent_disruptions_of_conversations [2019/09/26 10:47] – created zeev | rfc:analysis:prevent_disruptions_of_conversations [2019/09/27 10:46] (current) – old revision restored (2019/09/27 05:36) derick |
|---|
| 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. | 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. | 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. |
| | |
| 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. | |
| |
| |
| ===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: |
| | |
| | <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. | 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=== | ===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. 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. | 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 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. | 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: | 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: |
| |
| 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. | 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=== | ===Unpleasant does not mean disruptive=== |
| 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. |
| |
| | |
| | ===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. |
| |
| |
| 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 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: | 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) |
| |
| |
| 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. | 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. |
| | |
| | |
| | |
| ===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. | |
| |
| |