3 ms·

>In case my point isn't obvious here, an explicit CoC has a number of advantages over a document like this one when it comes to actually resolving conflict, ins

>In case my point isn't obvious here, an explicit CoC has a number of advantages over a document like this one when it comes to actually resolving conflict, instead of trying to prevent it. It makes value judgements, but only because at some point in the conflict resolution process, leadership will be forced to make value judgements. I disagree. Sociopaths weaponise hard and fast rules. It's better to not make rules that aren't required and stick to communicating as people rather than attempting to rule like computers. Don't choose to be a bureaucrat, choose to be a leader. Put another way, there's no substitute for not being a horrible human being. Projects that have good people on them have no need for CoC's. Horrible people will not stop being horrible because there is a CoC there, nor will a CoC drive them away. I don't really feel like getting into a roleplay with you about your specific Angry Project Lead scenario on hacker news, it's a bad forum for that since such discussions tend to be long and nuanced, but you should remember that when you have to tell someone their behavior is a net loss for their organization, it's never going to be a fun conversation. Obviously the person will protest, and depending on their personality that might range from pleading to outright physical aggression. Everyone coming away from such discussions feeling unhappy is normal, what matters is that there is some form of resolution in the process. Yeah, the outcome might be a forked project, or it might be someone being asked to leave. Those are not comfortable outcomes but they are hopefully necessary, otherwise why bother to have the conversation? As long as you can bring the project to a state where you've moved past the obstacle and it's no longer at the forefront of peoples minds, you've succeeded. If people are still discussing your ruling and what it means for contributors months or years later, you've failed. If resolution can be achieved without verbal, societal, technological or physical violence, that's the best that can be asked.

joshuamorton 8y ago
>I don't really feel like getting into a roleplay with you about your specific Angry Project Lead scenario on hacker news FWIW, I don't really either, I mostly just wanted to illustrate that not having guidelines or policies about how issues will be handled can lead to problems (like arbitrary enforcement, or accusations of arbitrary enforcement or choosing favorites, etc.). Guidelines for enforcement help protect leadership from accusations of such from contributors, and help protect contributors from actual inconsistent enforcement of the expectations. >Projects that have good people on them have no need for CoC's. Horrible people will not stop being horrible because there is a CoC there, nor will a CoC drive them away. But being "good" or "bad" isn't a binary. Its difficult, if not impossible to classify people as good or bad. Actions can be good or bad, generally speaking, but people rarely ever fit nearly into one box or the other. Is Linus a good person or a bad person? Maintaining Linux is a good thing, but abusing contributors is probably bad. A code of conduct may not itself magically drive toxic people away (although in some cases I think it will). But it does hopefully empower people who are not in positions of relative power in a project to call out bad behavior by those who would previously be protected, with an assurance that the maintainers will take it seriously (or the ability to call out the maintainers for inconsistently enforcing the guidelines). Conflict resolution is difficult, but that means that the conflict resolution policy, which is in many was what a CoC is, should directly address what happens when there is conflict. "Be kind to each other" doesn't do that, nor does a list of suggestions to communicate kindly. I think the best comparison is something like incident management policies. Sure, you expect that the systems you rely on will fail only very rarely, but you still have playbooks and systems in place to manage what happens when they do break. The Kind communications define an SLA for interpersonal communication, but don't describe policies to investigate or remediate when the SLA may be violated. >I disagree. Sociopaths weaponise hard and fast rules. It's better to not make rules that aren't required and stick to communicating as people rather than attempting to rule like computers. Don't choose to be a bureaucrat, choose to be a leader. Before anything else, I'll note that while abuse thrives on hard and fast rules, it also thrives on ambiguity. One must strike a balance when writing a guideline like this to both explicitly empower the agent of conflict resolution with the ability to resolve conflicts, and to not be so overly regimented as to allow abusive behavior to continue by claiming that it wasn't explicitly banned or whatever. Transparency and consistency is an important part of leadership. If the people you lead can't trust you or hold you accountable, it becomes problematic. In work environments this results in all kinds of things, but in OSS it results in people silently leaving, or just not joining in the first place. >If people are still discussing your ruling and what it means for contributors months or years later, you've failed. That depends. Which people? Someone can kick out anyone who disagrees with them about anything and be left with an effective, if small if perhaps somewhat sycophantic group of consistent contributors. Such a project would likely pass this bar of ruling well, but the project is also likely toxic. I don't know that I have a better solution, but I might suggest "In general people who don't get their preferred outcome are content to continue working on the project".
- Sir_Substance 8y ago
  All of those are true and reasonable points. Mostly what I take away from this is that no solution suits all situations.
  - joshuamorton 8y ago
    I'm in total agreement. Its not an easy problem to solve, and abusers will try to take advantage of the framework no matter what. My expectation though, is that this won't have the intended effect and won't be any better (and likely worse in a number of ways) that "conventional" CoCs which, despite the hate they get, appear to be one of the best solutions we have to this problem.

joshuamorton 8y ago

>I don't really feel like getting into a roleplay with you about your specific Angry Project Lead scenario on hacker news FWIW, I don't really either, I mostly just wanted to illustrate that not having guidelines or policies about how issues will be handled can lead to problems (like arbitrary enforcement, or accusations of arbitrary enforcement or choosing favorites, etc.). Guidelines for enforcement help protect leadership from accusations of such from contributors, and help protect contributors from actual inconsistent enforcement of the expectations. >Projects that have good people on them have no need for CoC's. Horrible people will not stop being horrible because there is a CoC there, nor will a CoC drive them away. But being "good" or "bad" isn't a binary. Its difficult, if not impossible to classify people as good or bad. Actions can be good or bad, generally speaking, but people rarely ever fit nearly into one box or the other. Is Linus a good person or a bad person? Maintaining Linux is a good thing, but abusing contributors is probably bad. A code of conduct may not itself magically drive toxic people away (although in some cases I think it will). But it does hopefully empower people who are not in positions of relative power in a project to call out bad behavior by those who would previously be protected, with an assurance that the maintainers will take it seriously (or the ability to call out the maintainers for inconsistently enforcing the guidelines). Conflict resolution is difficult, but that means that the conflict resolution policy, which is in many was what a CoC is, should directly address what happens when there is conflict. "Be kind to each other" doesn't do that, nor does a list of suggestions to communicate kindly. I think the best comparison is something like incident management policies. Sure, you expect that the systems you rely on will fail only very rarely, but you still have playbooks and systems in place to manage what happens when they do break. The Kind communications define an SLA for interpersonal communication, but don't describe policies to investigate or remediate when the SLA may be violated. >I disagree. Sociopaths weaponise hard and fast rules. It's better to not make rules that aren't required and stick to communicating as people rather than attempting to rule like computers. Don't choose to be a bureaucrat, choose to be a leader. Before anything else, I'll note that while abuse thrives on hard and fast rules, it also thrives on ambiguity. One must strike a balance when writing a guideline like this to both explicitly empower the agent of conflict resolution with the ability to resolve conflicts, and to not be so overly regimented as to allow abusive behavior to continue by claiming that it wasn't explicitly banned or whatever. Transparency and consistency is an important part of leadership. If the people you lead can't trust you or hold you accountable, it becomes problematic. In work environments this results in all kinds of things, but in OSS it results in people silently leaving, or just not joining in the first place. >If people are still discussing your ruling and what it means for contributors months or years later, you've failed. That depends. Which people? Someone can kick out anyone who disagrees with them about anything and be left with an effective, if small if perhaps somewhat sycophantic group of consistent contributors. Such a project would likely pass this bar of ruling well, but the project is also likely toxic. I don't know that I have a better solution, but I might suggest "In general people who don't get their preferred outcome are content to continue working on the project".

Sir_Substance 8y ago
All of those are true and reasonable points. Mostly what I take away from this is that no solution suits all situations.
- joshuamorton 8y ago
  I'm in total agreement. Its not an easy problem to solve, and abusers will try to take advantage of the framework no matter what. My expectation though, is that this won't have the intended effect and won't be any better (and likely worse in a number of ways) that "conventional" CoCs which, despite the hate they get, appear to be one of the best solutions we have to this problem.