This thread was for community feedback to the last draft. The comment period is closed, the comments have been taken into account and the update Code of Conduct has been posted to its own page now.
Thank you all for your valuable feedback.
We accept that jokes and trolling can be taken too far and are not valid excuses for the alienation of our intellectual peers.
It looks like a good charter that will preemptively help us with conflict. But I have two issues. First, not enough of a focus on our responsibilities as developers... HMN should be about making great software that we know won't make life worse for its users or society at large. It's nice to be nice to each other, but at the end of the day, I'm here because HMN is about something.
Secondly -- and I'm only bringing this up cause I don't think a lot of people would -- the use of the word "unanimously" sticks out to me. Consensus-based decision-making is bad because it means disagreements can only be resolved if someone pretends to have changed their mind or gets pushed out. Better to have someone speak their mind and lose in a vote than not speak their mind at all, for fear of dragging everyone else down. I've run into this problem countless times before, with groups ranging from my workplace to camping trips to Occupy. If you're not convinced by me, there's an excellent 1970 essay from a radical feminist that goes into depth about this http://www.jofreeman.com/joreen/tyranny.htm
Agreed that software quality probably won't be a huge concern, and is not something that seems usefully enforceable in a productive way. Would you ostracize somebody because enough community members thought their project was bad?
Also replying to amend my suggestion. I think "community members" is no good when considering ratchetfreak's post on the other thread.
We try to minimize the emergent complexity of tightly coupled systems, avoid the over-complication inevitably resulting from blindly applying accepted strategies without clear understanding of their immediate benefits, and we prefer that which is simple to that which is easy. When uncertain, we make measurements and follow the data.