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