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.

I know other people may not like this, but perhaps there should be a rule that we leave politics out of the forums. We can have our own community where that stuff doesn't have to seep in.

We accept that jokes and trolling can be taken too far and are not valid excuses for the alienation of our intellectual peers.

I get what you're saying here, but "intellectual peer" often means "someone on your level", so this phrasing might leave room for misinterpretation.

Other parts of the doc specifically mention not being rude to somebody for not knowing as much or having as much experience. Given that, I feel something like "community members" or "peers" without the "intellectual" qualifier might better capture the spirit of what you were going for.

The code of conduct also kind of reads somewhat like a mission statement (specifically the Individual points, which I do like). Is that the intention? I'm not experienced with codes of conduct for other communities other than having just read the Ubuntu and Python ones linked.

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

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

I wouldn't worry about that, Oswald. We are first and foremost about software. That's the thing that brings us together, why we're all here. The Manifesto is part of the charter. These two parts are primarily about our interaction with each other now that we're here, they don't in any way replace the original mission statement.

Oswald_Hurlem
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

Thusfar this has not proven to be an issue. Abner, Andrew and I all practice the scientific method. We're okay with setting aside our investment in a position if new evidence renders it untenable. That said, we haven't had disagreements about the direction we should take something yet in over a year. If and when that should happen, we'll do the responsible thing and deliberate based on evidence.

We can always reconsider changing that clause to a majority decision with the dissent noted, SCOTUS-style, should we find ourselves in a deadlock on a position of some importance, rather than say decide what new kind of pizza Abner should try.

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.

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

Then perhaps we simply mean to say: "any person".

Mr4thDimention
Then perhaps we simply mean to say: "any person".

:+1:

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.

In my experience, "immediate benefits" are exactly the reason why accepted strategies are blindly applied. It's the costs that are often ignored. For example, I could choose to use Unity because of the immediate benefit of a ready-made editor and a simulated game world ready to receive objects, while completely ignoring the long-term costs that will hamper my ability to make the game I want to make.