[Development] QUIP 12: Code of Conduct

Fri Oct 26 08:55:09 CEST 2018

Even if I'm just living in the outskirts of the Qt Project (have for a long
time) I just have to say I wholeheartedly agree with Thiago in his thoughts
below.

One comment inline below.

Den fre 26 okt. 2018 07:14Thiago Macieira <thiago.macieira at intel.com> skrev:

> 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.
>

Absolutely. And one thing I've when doing code reviews at work is that it's
_very_ effective to not only point out problem areas of where things should
be done differently, but also point out parts that are particularly good,
as encouragement. The reviewee will feel better, and be more productive,
producing even better code.

Humans are quite simple in that sense :)

So it's absolutely not only about code.

Elvis

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
>
>
>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20181026/dad62222/attachment.html>