[Diversity-talk] Code of Conduct & Moderation for this list

Paul Norman penorman at mac.com
Thu Mar 1 18:13:49 UTC 2018


On 2/28/2018 2:44 AM, Rory McCann wrote:
> Hi all,
>
> To follow up on the phone call, and waiting a little bit for people to
> join. 😁
>
> I think this list should have a Code of Conduct. I propose something
> like Geek Feminism's one. Thoughts?
>
> http://geekfeminism.wikia.com/wiki/Community_anti-harassment/Policy

I see nothing wrong with a mailing list deciding on rules for how they 
moderate themselves. Before setting rules, it's important to identify 
what behavior is an issue. With OpenStreetMap Carto's (osm-carto) Code 
of Conduct, I wanted to start with text that covered derailing topics, 
including by taking issues off-topic. osm-carto went with a CoC based on 
that of Go.[1]

The other codes of conduct that made my list for consideration were 
those from Debian, FreeBSD, Go, Joomla, Puppet, GNOME, Julia, and KDE. A 
downside to this list is that they're all software development related 
projects. OpenStreetMap Carto is similar to one[2], but OpenStreetMap 
isn't a software project. I would want to also consider what other 
non-software volunteer groups are doing. Some that kind to mine are 
cycling associations, ramblers, and other groups which OSM has a strong 
tie to.

A couple of issues I would consider if I were doing the selection again 
are readability and education or socioeconomic status. Readability is a 
big problem with many codes of conduct. The Go CoC comes with a score of 
11-13,[3] and I'd want 8-10 at most. This is better than the Geek 
Feminism one, which scores 13-15 and uses a lot of jargon.

For education and socioeconomic status, I can't say it any better than 
Richard Fairhurst did [4]:

> Volunteer communities in general, and open source software in 
> particular, can be unwelcoming places for people from poorer 
> backgrounds or without a university/college education. Wealthy, 
> educated people - which most open source contributors are - can easily 
> dismiss contributions from such users through rhetorical skill, 
> through sniping on grammar/spelling etc., and through belitting their 
> concerns as not representative of the empowered, educated group.
>
> Increasingly I have noticed that contributors from these [areas where 
> residents have typically benefited from as good an education, and have 
> less well-paying jobs] find it hard to articulate their views on the 
> site without being shot down by the wealthier, more educated majority. 
> This might take the form of the majority criticising minority 
> contributors over minutiae (small sincerely-believed factual 
> inaccuracies, grammar/spelling); or a deliberate unwillingness to 
> tolerate assumptions that differ from the majority; or constructing 
> means of engagement/consultation that are less open to those from 
> poorer backgrounds (evening meetings arranged which are effectively 
> closed to those unable to get childcare, etc.).
>
> My open-source background is largely in the OpenStreetMap project 
> where there has been a fair amount of academic research done into 
> contributor biases (particularly, though not entirely, through the 
> work of Professor Muki Haklay). The result of such bias is easy to 
> visualise in OSM: wealthy areas such as London or San Francisco are 
> mapped in much more detail than poorer areas such as the Welsh Valleys 
> or the rural American Midwest. However, although the prevailing 
> open-source narrative has led to a fair amount of (welcome) discussion 
> as to how we can welcome and help those groups traditionally 
> considered marginalised in technology, there has been little or no 
> thought given to how we make ourselves more welcoming to poorer or 
> less well educated people. Indeed, there are instances of where such 
> contributors have received a hostile reception on the project's 
> communication channels (mailing lists, on-site discussions).


[1]: The reporting mechanisms weren't suitable for a small project
[2]: It's style development, but we communicate over issues, pull 
requests, and similar means.
[3]: Sometimes called grade level, but that leads people to bad 
assumptions about what level of education is needed to understand a 
piece of text
[4]: https://github.com/ContributorCovenant/contributor_covenant/pull/491



More information about the Diversity-talk mailing list