add code of conduct

[mr-c]

• Is it mergable?
• Did it pass the tests?
• N/A If it introduces new functionality in scripts/ is it tested?
  Check for code coverage.
• Is it well formatted? Look at make pep8, make diff_pylint_report,
  make cppcheck, and make doc output. Use make format and manual fixing as needed.
• Is it documented in the ChangeLog?
• Was a spellchecker run on the source code and documentation after
  changes were made?

[mr-c]

@ctb ready for review and merge

Preview the changes at http://athyra.ged.msu.edu/~mcrusoe/kdocs/dev/index.html

[camillescott]

Is the issue tracker really an appropriate venue for discussing instances of harassment?

[bocajnotnef]

It does make for a rather transparent resolution process, which (in most cases) is good for all those involved. If it's an issue that folk would prefer to remain private there was the option of contacting one of the maintainers.

[camillescott]

Perhaps, but the people who are most likely to run into harassment are also least likely to choose a public solution, and having it there as an option creates a huge potential for animosity when someone does choose to resolve it privately.

[mr-c]

I'm going to add the khmer-project@idyll.org into this to make it super clear that direct email is A-OK.

[camillescott]

My point is more that having the public route there as an option at all creates a privilege gradient.

[bocajnotnef]

i.e. someone's method of resolving harassment is another thing to be harassed over, or that we (the project) will respond more/care more about one method above the other?

[camillescott]

Both. You really want to minimize undercurrents of animosity in these situations, as they can take something that was apparently resolved and reanimate it.

[bocajnotnef]

Mm, fair/reasonable. Would having any sort of public response be a bad idea? i.e. some variety of statement by us that we've encountered an issue and are resolving it? I'm not sure handling all this behind closed doors fits with the mentality of the rest of the project but I don't really have a suggestion on how to avoid that while keeping initial communications private.

[camillescott]

It's probably okay to make that sort of statement; it's just usually best not to name names, if it can be avoided.

Radical openness only works with human interaction in practice when there is a level playing field. Our society is nowhere close to that, thus necessitating codes of conduct in the first place.

[mr-c]

This is, of course, a draft. I appreciate the feedback so far! I'm going to read https://adainitiative.org/2014/02/howto-design-a-code-of-conduct-for-your-community/ and ponder all of this

[camillescott]

Definitely something that should be constructed collaboratively. I'd also like to hear from @ctb re: the genesis of this addition, etc.

[mr-c]

@ctb retweeted a link to this document and I made the PR on my own.

[camillescott]

Cool! Looking forward to further discussion. Other than the issue tracker thing, it looks pretty good to me.

[ctb]

Would suggest "By participating in the development of this project you agree to abide by its terms."

[ctb]

I agree that the issue tracker is not the place; make it the khmer-project e-mail.

Two thoughts - first, spell out who is on khmer-project, and second, provide an ombuds backup, in case the complaint is about me or @mr-c. We could ask Judi Brown Clarke to be the backup.

[ctb]

(But yes, I'm glad Michael added it to the project!)

[mr-c]

(Thanks) +1 on JBC as the backup. Let me know when you've secured her
permission

On Wed Nov 19 2014 at 4:27:12 PM C. Titus Brown notifications@github.com
wrote:

(But yes, I'm glad Michael added it to the project!)

—
Reply to this email directly or view it on GitHub
#664 (comment).

[ctb]

jbc@msu.edu.

[ctb]

Oh, never mind. That's her From address :)

[mr-c]

Yeah, I pulled the info from her email signature :-)

[ctb]

LGTM. Make it mergable & then merge!