[MirageOS-devel] Minimum Community Standards and Best Practice

[Lars Kurth <lars.kurth@xxxxxxxxxx>]

Dear Community Members,

at the 2017 Developer Summit the question of a Code of Conduct (CoC) for the 
Xen Project had come up and subsequently a number of individuals within the 
community have looked at the question of whether we should have a CoC or not. 
Note that there was a discussion at the last community call: see 
https://cryptpad.fr/pad/#/2/pad/edit/WZr2VTdfmaPdvIxjXp+cgSF-/ 

This never really led to anything except for some discussions amongst a subset 
of individuals, but since then 
* A large number of open source projects (including the Linux kernel) have 
adopted Code of Conducts
* I have seen an increase in friction when we communicate and also an increase 
of complaints about specific interactions (both from newcomers, as well as 
established community members). Note that when I looked over the complaints 
with the help of some trusted community members, none of the complaints would 
actually have been violations of commonly used Code of Conducts. But these are 
an indication that there is maybe something that is not healthy and needs 
fixing in our community.

As we have the Developer Summit coming up AND we have all of our committers 
there (with the exception of maybe 1), I feel very strongly that we should take 
the opportunity to discuss and try to find a constructive way forward. I took a 
couple of actions at the last community call and last Advisory Board meeting 
including an investigation. This e-mail is one of the outcomes.

The following is structured into two parts: 
* Code of Conducts 
* Best Practice : this is how I believe how we should be able to solve most of 
the issues that I have seen or received complaints about recently

# Code of Conducts
## Code of Conduct Patterns and Examples

The majority of Code of Conducts that are widely adopted in Open Source 
Communities are modified versions of one of the following sources
[1] Contributor Covenant: http://contributor-covenant.org/
[2] Django: https://www.djangoproject.com/conduct/
[3] Citizen Code of Conduct: http://citizencodeofconduct.org/
[4] Geek Feminism: http://geekfeminism.org/about/code-of-conduct/

A general pattern in these examples is to 
[a] Outline values/scope
[b] Outline desired behaviour
[c] Outline unacceptable behaviour and 
[d] Outline possible consequences of what happens when complaints are made and 
how a decision to impose consequences are reached

Note that [4] is an exception in that it very much focusses on [a], [c] and [d] 
only. 

Also note, that we have followed a similar CoC at our Developer Events for 
several years: see
[5] https://events.linuxfoundation.org/code-of-conduct/

## Recent Controversy about CoCs

It should also be noted that the introduction of CoCs into open source and 
technology communities has created controversy recently. Most notably around 
the introduction of a CoC in Linux. Rather than participate in this debate, I 
am merely going to provide some examples - note that some of the quoted 
articles could be offensive to some
[6] https://itsfoss.com/linux-code-of-conduct/
[7] 
https://modelviewculture.com/pieces/the-new-normal-codes-of-conduct-in-2015-and-beyond
 
[8] 
https://www.breitbart.com/tech/2016/01/25/ruby-hackers-in-revolt-after-sjws-attempt-to-impose-politically-correct-code-of-conduct/
   

Looking at some of this, it appears to me that we ought to do the following
* Establish a set of Minimum Standards which ought to be non-controversial. The 
term Minimum Community Standard, or maybe something even clearer such as 
"Unacceptable Behaviour Policy" is in my view preferable to using the term CoC. 
This would basically be the law of the land: it would have to be clearly 
formulated around unacceptable behaviour in your workplace such as abuse, 
bullying, ... but not aspirational behaviours. We would have to set up a 
mechanism to report issues and enforce it. It would primarily be an insurance 
policy for the future: note that we have not had any issues. We can use 
existing baselines, such as [4] or [5] and adapt these accordingly, which 
primarily means designing the reporting and resolution mechanism. As we follow 
[5] at our events already, I would probably start with [5] 
* Carry our community members along when introducing the CoC: 
   My intention is that this mail is the start of this process and that we 
discuss further at the developer summit  
* We separate out EVERYTHING that is aspirational into a separate mechanism, 
which addresses specific problems we have today and aim to create a healthier 
and friendlier environment which for now I call Best Practice, but this is 
probably a wrong label. My initial thoughts about this are outlined in the next 
section

# Best Practice / Healthy and Productive Environment
This is an area where we have real problems today and where I also regularly 
receive complaints. In a nutshell, we are not the most friendly and welcoming 
open source community and are often much more confrontational than we should 
be. The issues we have in this area affect EVERYONE: this includes committers 
and long-standing contributors. Fixing this is not something which is easy, but 
I can believe it can be fixed if everyone tries to pro-actively reduce 
unnecessary friction (because of different cultures, priorities, communication 
styles, personalities, …). 

I don't have clear answers, which means we really ought to discuss, prioritize 
and come to some sort of consensus at the summit. 

## Examples
To make this more real, some examples where I keep getting complaints primarily 
around xen-devel@ interactions are around persistently
* Unnecessary bikeshedding
* Communication styles and misunderstanding, most frequently
   - Sometimes this is perceived as rudeness
   - Comments without clear indication on how to fix the issue
   - Use of words that are hard to understand for non-native speakers
   - Etc.
* We are not specifically welcoming to newcomers 
* We have higher standards than most when it comes to code contributions, but 
we have not agreed or documented our standards
   - An example raised by Christopher was that the project has VERY HIGH 
standards on language of commit messages
   - We also have high requirements when someone contributes to an area of code 
which has technical debt issues: we often in this case ask the contributors to 
fix issues.
   - Etc.
* Decisiveness, clarity and consensus
   - We are generally not very good at resolving disagreements and often allow 
unresolved issues fester
   - This is particularly bad when we have multiple committers reviewing a 
portion of code and have lengthy arguments
      - This leaves community members who don’t work on an ongoing basis on the 
project uncertain of a clear direction
      - It sets a bad example
   - Even when we do resolve an issue, we often do not codify the outcome (e.g. 
in coding styles)

This is not a complete list. I believe that we ought to discuss this in more 
detail at the summit and I was encouraged in the community call that most feel 
that 
a) we have a real issue and 
b) that there is willingness to contribute to addressing these.  
I do also know - and to some degree this applies to me as well - that 
non-native English speakers sometimes have problems specifically with 
Communication styles and misunderstanding

I do have some concrete ideas in this area, but I do not want to share these 
yet as this might influence the discussion too much. I do believe that none of 
this can be addressed through a Code of Conduct or process. It requires more.

Looking forward to get some more views.
I also will create a design session for the Developer Summit

Best Regards
Lars

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/mirageos-devel