[Xen-devel] Minimum Community Standards and Best Practice

[Xen-devel] Minimum Community Standards and Best Practice

[Lars Kurth]

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

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel