[Development] QUIP 12: Code of Conduct

[Thiago Macieira]

On Wednesday, 24 October 2018 00:17:09 PDT Ulf Hermann wrote:
> Hi,
> 
> regarding our earlier discussions on a possible Code of Conduct, here as
> well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> necessary rules and definitions:
> 
> https://codereview.qt-project.org/243623

Hello Ulf and everyone else on this thread

I've posted a few comments here and there relating to the process of adopting 
anything in our community, but I haven't yet voiced my opinion on this 
subject. This email is it.

Note that even though I am speaking for myself, I understand my opinion 
reflects on my employer. So I want to say this first: Intel does support Open 
Source Projects adopting Code of Conduct as well as actions leading to 
increasing access and diversity of ideas, hopefully leading to improved code. 
We also particularly like the Contributor Covenant text.

I am also personally in favour of adopting a CoC and I support adopting either 
the Covenant text or KDE's. Both are fine to me. Another good one is 
Mozilla's[1], which the SQLite developers have just adopted too.

In fact, I was there 10 years ago when KDE decided to adopt something. Back 
then, I was also of the opinion that we shouldn't need anything. The KDE 
community had always been a welcoming one: in my first Akademy, I was greeted 
by people I had only met online as an old friend. Moreover, the KDE community 
had always resisted any kind of formal structuring of anything, which led to 
the Technical Working Group being created and disbanding in 2006. Even today, 
the KDE e.V. takes great steps to make sure it is never seen as a ruling body.

But the CoC was adopted, with no ill effects. I do not have direct knowledge 
of where they had to intervene, if at all, but I'm told it has happened. More 
importantly, I have also grown as a person since then. In a particularly 
telling moment, when a female colleague here in the office (located in a very 
affluent, liberal and progressive part of the US) once asked my opinion on the 
Python Donglegate incident and explained to me the reason why she interpreted 
it the way she did, I realised how my worldview was so very different from 
hers. I've come to understand how little things that did not bother me were 
highly offensive to her.

I've seen basically three questions asked by the skepticals to this proposal:

1) if it ain't broke, why fix it?

To put it simply: the CoC has as an objective make sure the community is 
always welcoming and inclusive. People have a limit on how much hostility 
(intended or not) they're going to put up with. If they reach that limit, 
they're going to simply avoid it and that can be anywhere from avoiding 
contributions to certain parts of the code to stopping contributing altogether 
(or worse). We don't want to lose them or their contributions.

Think of the CoC as preventive maintenance: you don't do it because it's 
broken. You do it so it *won't* break in the first place.

2) why not let the code rule?

Code does not exist in isolation and the Qt Project is not a set of files in 
Git. The Qt Project is a community that maintains that code, so we need rules 
beyond code. We have contributors who don't contribute a lot of code, but that 
does not make them any less important members of the community.

Besides, any commit comes with a commit message. Any review comes with 
feedback and there are few that are simply "+2" with no text. We want good 
code, improving Qt and for that we need to interact with one another. 
Moreover, the major architectural issues are not discussed in code, but in 
prose via email. 

Finally, being good at C++ is not an excuse for being a jackass. No one should 
get a pass because they're experts at something. We can't make the cold 
calculus that "person X's productivity is worth 10 new contributors so we will 
allow X's behaviour to turn away 10 contributors". What happens on the 11th? 
And what if one of those turned out to be amazing after a few months?

So clearly code is not enough.

3) how do we prevent ill side-effects and abuse?

One ill side-effect would be the turning away of important contributors who 
feel that the adoption of the CoC stands in the way of their participation. 
But please note that has not happened to any significant manner in any of the 
big Open Source Projects that have adopted CoCs. That includes the Linux 
kernel: despite what you may have heard in the media, the kernel maintainers 
and Linus himself subscribe to the new CoC and Linus has returned to 
development.

We can also work with that person to find a compromise solution. I find it 
hard to believe we couldn't, if that person is willing to see the other side 
of the coin. And I speak from experience on that.

The rest should be in the CoC text itself and how it empowers the resolution 
committee to make its decisions as well as any checks-and-balances on the com
committee itself.  Specifically, the CoC should not be used to discriminate 
against one's political views any more than on another's sexual orientations. 
And what you do on your private time is your own business.

[1] https://www.mozilla.org/en-US/about/governance/policies/participation/
-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center