| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| rfc:analysis:prevent_disruptions_of_conversations [2019/09/27 05:28] – WIP zeev | rfc:analysis:prevent_disruptions_of_conversations [2019/09/27 10:46] (current) – old revision restored (2019/09/27 05:36) derick |
|---|
| ===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=== |