The steering committee folks sound like a microcosm of a communist poliburo. Aiming for who can be the most offended over imaginary slights.
I'm glad as An American tax payer that we're not funding an organization with such petty politics and discriminatory behaviors.
Tim sounds similar to John Carmack recent she post about Meta:
> I wish I could drop (so many of) my old internal posts publicly, since I don’t really have the incentive to relitigate the arguments today – they were carefully considered and prescient. They also got me reported to HR by the manager of the XROS effort for supposedly making his team members feel bad
Not having such a committee in power and most likely no COC. The FSF's Kindness COC sounds good though.
Within perl we treated conference abuse privately in a seperate nonpublic group, but never mailinglist outbursts. This group had no power over anyone else. Esp. over devs with different opinions, who critized core devs over their work.
Glad to hear one programming community is handling the issues in what sounds like a healthy way.
It also requires actual human effort though, so it's difficult to do. People hate doing difficult things and prefer to be part of "witch hunts" because they're easy IMHO. Discussion and discourse is key.
I've come to the conclusion that this is how it needs to work:
1. As the first person on the project, assume BDFL status and prepare to act that way as soon as you consider accepting a PR.
2. As a person, make sure you strongly understand what your moral values are, and why you hold them.
3. Proactively write your own Code of Conduct from scratch. It's important to have one so that you will not be pressured to use someone else's. It's important to ensure that it reflects your own values, not those of some activist organization (or another project that has been co-opted). Make it simple, but feel free to refer to additional documents. https://compass.naivete.me/ can be considered an example (this is not an endorsement, and again my recommendation is to write it yourself from scratch).
4. Do not have an "Enforcement Procedures" document, and actively reject any such proposal. The interpretation of your code of conduct should be apparent from the text itself, given a reasonable-person standard; you do not need to try to formalize the notion of a reasonable person.
5. If people think you are being unreasonable in your project governance, take that discussion somewhere else.
6. Remember at all times that everyone is free to fork your project. If people wish to do this over a governance dispute, it would be better for it to happen now than later. Do not try to prevent this from happening: do not attack the efforts of others (as has happened to XLibre), and also do not negotiate with others out of fear that they might start a fork. If they start a fork it is of no concern to you.
7. Only dictatorships and democracies are stable. While you are in charge, power rests only in those you directly appoint, and you may revoke this if necessary. When you are ready to leave, unless you have in mind a 100% trusted successor, ensure that your replacement is elected and that the project has a charter such that power can only rest with elected individuals.
Asking for the right one-size-fits-all system skips doing the systems thinking up front.
A failure mode with a lot of community management systems is that they're adopted because they have a general vibe of keeping the bad people out. And that vibe will see any criticism of the community management document/team/actions as a way to sneak the bad people in.
Imagine I told you I found a rando discord server dedicated to a tabletop RPG I love, but complained that the moderation team was a clique. I claimed that I feel forced to fit in by pandering to their sensibilities and biting my tongue on other topics even if they're just flat out provably wrong. Nobody would assume I'm just salty because I secretly want to post porn, cuss and be racist in #general. Because we all know discord mods are notoriously petty tyrants.
Now give that discord community a github page and copy-paste in an HR document. The way expectations snap into treating them like levelheaded professionals with unassailable intentions and righteous goals is the reason this topic always goes nowhere.
