At its meeting today, the THATCamp Council has agreed to post the following draft of an anti-harassment policy for editing and comment. This is revised version of the Code4Lib anti-harassment policy, which in turn is based on the Geek Feminism anti-harassment policy.
We envision this as a document that all THATCamp organizers must agree to adopt before they can register a THATCamp. We’ll be taking comments this summer until August 30th (please comment on this blog post) and will produce revisions in accordance with those comments. We’ll vote to adopt the Code at the next THATCamp Council meeting, which will take place sometime in September 2014.
This seems to cover the increasingly agreed-on basics. It might be nice also to open with a less formal “short version” along the lines of the PyCon Code of Conduct. That would retain the usual THATCamp tone before laying out the (necessary) formal details of the policy. As a camper and (possibly someday) host this seems comfortable with or without that.
Hmm, a short version is a good idea, Chris — thanks.
Let me know if I can help.
One small suggestion, and one broad pattern observation
Small suggestion: maybe expand
To either “produces an unsafe or unwelcoming environment” or “produces an unsafe or uninclusive environment”. Implicit in those options is what’s the difference between unwelcoming and uninclusive. I lean a little toward the “uninclusive” language, as to me it says that challenging ideas can sometimes be unwelcome, but still done in an inclusive way.
Broad pattern thing:
We’d described using for “non-public” concerns, which might include harassment problems in forums (or possibly in comments on individual sites/camps?). This doc also suggests contacting Council members. But for any particular situation at a THATCamp, the target of and any council member won’t likely be in a position to take immediate action. I’m good with saying info/council member is a good, safe, non-public place for anything on thatcamp.org, and also for situations that happen at any particular THATCamp that call for non-immediate attention. But I worry about suggesting info/council members can respond to immediate issues at a THATCamp. It’s the synchronous vs. asynchronous ability to take action that I’m fretting over here. It’s probably not realistic to say that a THATCamp Council member can take meaningful immediate action at any particular THATCamp, and so I worry about suggesting that we can by saying contact us in the initial incident phase if the initial incident is at a THATCamp.
On the site, in forums or in any particular THATCamp’s site and discussion, definitely info / any council member is an appropriate place to report.
Do we also want to say that THATCamp Council is an explicit resource for THATCamp organizers unsure about how to resolve an issue? If an issue comes up that an organizer is unsure how to respond to, is an anonymized forum post an appropriate way to get guidance? This touches on how THATCamp Council sees what it can and cannot realistically do to help.
Great points, Patrick. (I too like “uninclusive.”) It does seem like the proper “flow” for reports is to a THATCamp local organizer, who should then notify and/or a member of the Council. But we should keep in something about reporting to info / the Council *instead* of to a local organizer, I think, though you’re right, with caveats that it might take us a couple of days to respond and so shouldn’t be used when urgent action is needed. But I can imagine reasons why someone might want to go to the Council directly.
When we meet, we should probably also declare when the policy kicks in. That is, already-registered THATCamps probably shouldn’t be required to follow the policy — it would be adding a requirement that they didn’t accept at the time of registration. When, then, do we add the checkbox to the requirements for registering a THATCamp?