"Be kind, generous, and accepting, or there will be consequences!" is just a few steps removed from, "The beatings will continue until morale improves."

The conundrum with linux, was that it was organized in a self-contradicting way. It's fine to have a meritocratic leader who is exacting and demanding, even harsh. You just don't mix that up with an ethos of accepting all contributors in public. Instead, there needs to be a public tier which is concerned more with outreach, and only once people are ready for the next level, should they be given access to the level where they have to stand and deliver.

>the appointed maintainer(s) of a GNU package can, if necessary, tell a contributor to go away; but we do not want to need to have recourse to that.

in his email, although leaves that out of the guidelines themselves. Why on earth is being forthright about the fact that abuse will lead to exclusion worse than being cagey about that fact? If the end result, you can be kicked out, is the same, why would you prefer that the circumstances be entirely up to each individual maintainer's discretion instead of a somewhat objective (and importantly, public and available!) set of criteria?

[1]: https://news.ycombinator.com/item?id=18275994

Exactly so that the same judgement isn’t applied everywhere. Different maintainers will end up having different audiences. I see that as acceptable, maybe even preferable.

Then you work as a group of not-socially-incompetent people to find a compromise solution that hits the local maxima of what can be done with the situation, or make a considered decision to move down from the local maxima in the short term to find a higher maxima in the long term.

Maybe discuss with that person the possibility of continuing their work but having a small group of other people between them and the general public as an interface layer that handles the less important work.

If you think that setting up such a compromise might either be too expensive, might risk burning out the interface people or has some other downside, maybe have a frank discussion with them about the benefits and costs of their contributions to the process.

Talking to people always works better than talking at people.

So you mean you want to unseat me from leading the project I'm in charge of? What kind of punishment is this for violating some silly guidelines? [1]

>If you think that setting up such a compromise might either be too expensive, might risk burning out the interface people or has some other downside, maybe have a frank discussion with them about the benefits and costs of their contributions to the process.

Wait, but I thought that this was a guideline. Are you saying that there's actually an implicit threat within this guideline that I might be removed from the project against my will? Why wasn't that stated explicitly? How am I, a valued contributor, able to make informed decisions if rules are arbitrary and decided on behind closed doors without any ability for public input, comment, or even knowledge?

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.

Making those value judgements explicit, and public, is a commitment from project leadership to not favor the in-group over the outgroup either explicitly or implicitly, when resolving conflict. It allows people to cite a prior commitment from the leadership to act in a certain manner. You still must trust the leadership to resolve conflict in the manner they stated they would, but you can verify that their resolution was in-line with the process and commitments they provided.

This doesn't mean that a CoC prevents leadership from attempting to mediate conflict when it comes up, and come to mutually agreeable solutions in cases when that is possible. But it does mean that in those rare cases when it is no longer possible to assume good intent that everyone is aware of the values that leadership and the decision-makers opted in to, and can hold them accountable to making decision in line with those values.

With this, Stallman hasn't made a commitment. He's written some nice platitudes, but when it comes down to it, how am I supposed to know if (again, hypothetically speaking) I'd had bad interactions with GNU or its members previously, Stallman would really value my experience strongly enough to take action instead of just letting me suffer to maintain the status quo? How can I try to hold him accountable when I don't know his values, and it would be completely possible for him to write off my complaint as simply not assuming good intent on the part of other contributors?

I can't. That's the problem.

[1]: Note that in this little hypothetical, you're my "boss", so the suggesting to put someone between me and the people I lead can be reasonably interpreted as a demotion or attack on my authority.

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.

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