Thank you Thiago for your well put thoughts. This is in line with my thinking as well.
I'm glad we are finally at the point of having this discussion, as it's been quite a long time since I hosted the Code of Conduct discussion at the 2017 contributors summit. https://wiki.qt.io/QtCS2017_Qt_Project_Code_of_Conduct What has been so surprising about the discussion so far is the assumption that the people pushing the Code of Conduct have a political agenda, because this is not at all where this drive started from. The Qt project currently is a really nice community who is very supportive and respectful of each other. The Qt community is aligned in achieving the same goals, and the work we do to achieve that is done in good faith. The whole point of the Code of Conduct was to codify those same values so we could maintain that. The choice of the Contributors Covenant as a starting point was arbitrary (I know, because I proposed it). The KDE and Mozzila CoC's are also just as acceptable in my eyes. Even looking at the notes for the CS2017 sessions, we were perfectly fine with the simple theme of "Be Kind. Be respectful". Nothing is set in stone at this point, everything is open to discussion still, even the point of whether we should adopt any code of conduct at all. Based on discussions I've had this week, one of the biggest sticking points with any CoC regards enforcement. Even if we have a one sentence CoC how do gross violations of the CoC get handled? If there is an email address for reporting incidents then who is reading/responding to that for example? The proposal that is part of https://codereview.qt-project.org/#/c/243623/ is also completely open to discussion evaluation. The discussion at CS2017 that led the current proposal was based off of this: "As part of creating the Code of Conduct, we will also establish a small private mailing list for usage in resolving breaches of the code. This would behave similarly to the Security mailing list. This proposal will be part of the draft submitted to the Qt Project for approval." The details of this are tricky though because it depends a lot on trust (similarly the security list). Much of the concern with this proposal has to do with the potential for abuse, and rightly so. I'm not super happy with the idea of a Conduct Cabal who has to the power to banish people from the community either. So maybe a better way of looking at this is, today if you felt were legitimately being harassed by another member of the Qt Project, what would you do? Who would you tell and what kind of reaction would you expect? My understanding of how things are handled today is that its very ad hoc, which is less than ideal as well. The way trust works in the Qt project so far is through the meritocracy so maybe a solution to any trust issues with enforcement can be solved in a similar way? I also want to make it clear that QUIP 12 can be completely different than what is in https://codereview.qt-project.org/#/c/243623/ and welcome a counter proposal based off the KDE CoC if someone would like to draft that. I look forward to hearing any thoughts and ideas. Andy Nichols -----Original Message----- From: Development <development-bounces+andy.nichols=qt...@qt-project.org> On Behalf Of Thiago Macieira Sent: Friday, October 26, 2018 7:15 AM To: development@qt-project.org Subject: Re: [Development] QUIP 12: Code of Conduct 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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
