[Development] QUIP 12: Code of Conduct
Simon Hausmann
Simon.Hausmann at qt.io
Thu Oct 25 12:33:45 CEST 2018
Am 25.10.18 um 11:50 schrieb Rafael Roquetto:
> I understand this has already been set in stone, and I am not here in
> the hopes this will change. However, I do feel like I should voice my
> own humble opinion - perhaps it can be useful, or maybe not...
Your feedback is most certainly useful. (at least in my humble opinion ;-)
> I would like to start by saying I fully agree with Shawn: what exactly
> are we trying to fix? That is not to say problems never happened, but
> these things have side effects - sometimes the most unintended ones. As
> C++ programmers, we should know well that unintended side-effects
> steaming from well-intentioned constructs are no exception (pun intended).
You're right, there can be side-effects. We have to be careful about those,
as much as we have to be careful to address the situation of uncaught
exceptions. Those terminating the process of contribution and potentially
causing further side-effects is what this is trying to "fix" or at least
attempt
to improve.
I think the best way to minimize the side effects you may be concerned about
is to ensure that the wording emphasizes the desire for a positive
environment
(for the purpose of reasoning) and also frames the part of handling
violations
as a last resort, as something that should be the exception.
If, on the other hand, a CoC is not used as a last resort but at the
beginning of
every slight misunderstanding, then we would perhaps have failed.
This is where input from other projects that have had a CoC, such as KDE, is
beneficial in assessing the risks.
> So I will go back to my question: what is it we are trying to solve? Or
> rather, what is it that happened, that we are trying to prevent from
> happening again? There will always be lunatics, and a CoC won't stop
> them. Perhaps it will improve things... but... perhaps it will do more
> harm than good. Or is it proven technology?
As I also said in my earlier email, I'm aware of at least one case
where terrible behavior resulted in a contributor with track record
of patches being turned away and no consequence for the person
responsible for it. That is unjust and I think doing _something_ about it
is better than us - the community - keeping quiet and sweeping these
exceptions under the carpet. The sweeping under the carpet, _that_ is
what we must prevent from happening again.
What are your thoughts about that?
>
> Which brings to my second point, a very personal one: more or less in
> line with what Jason said, programming *to me* has always been about
> bits and bytes, about the code, about computers, about being able to
> make things appear on the screen and to control the machine. Free
> Software has been about.... free software and that's it. I find it
> extremely off-putting to see that the Qt project is embarking in this
> sort of politics - again, if things were broken and a CoC could fix
> them, I would be more than happy to join the train, but that doesn't
> seem to be the case. At least from my humble perspective.
I think it should be like that, at the heart of it.
On the other hand much has happened in the world since the early
days of free software projects. A much larger part of the population
on the planet has access to the internet and education that makes it
possible for them to join our community. I think that is a fantastic
opportunity. It means that people different backgrounds, different cultures
and different upbrinings are able to join. We must assume good faith,
but we should be prepared to be able to explain what we would perhaps
consider "common sense" in terms of behavior. A well worded document
may be of tremendous help.
This is one aspect I really like about the GNU Kind Communications
Guidelines
as an alternative. It's _something_ more than what we have today.
> During all these years contributing to Qt I have encountered many times
> strong criticism in gerrit - some people were very harsh or *seemingly*
> rude - or that was what I thought, until I realized that: 1) it was just
> their modus operandi; 2) at the end of the day, their comments made
> sense and improved my code; 3) they were not butt hurt when roles were
> reversed.
>
> Communication/criticism just like this is unambiguously straightforward
> and I *personally* prefer it this way. Unfortunately I could not make it
> to the QtCS, but had I been there, I would have voted against the CoC,
> for sure. I hate to see politics tainting the project. But, that is my
> view, and in spite of that, I do hope that in the end I am wrong and
> that the CoC is another step on the right direction. Let's remain
> positive and hope it won't even be necessary to invoke it after all, and
> that respect and common-sense shall prevail.
>
Calm and well formulated emails like yours help big time to maintain
a positive attitude in this discussion and increase chances of a good
result for the project - thank you :)
Simon
> - Rafael
>
> PS: if you have read this far (sorry!), you may also be interested in
> donating a tad more of your time and help with reviewing this
>
> https://codereview.qt-project.org/#/c/241598/
>
> ;)
>
>
> On 10/25/18 5:58 PM, Lars Knoll wrote:
>>> On 25 Oct 2018, at 09:51, Volker Krause via Development
>>> <development at qt-project.org <mailto:development at qt-project.org>> wrote:
>>>
>>> On Thursday, 25 October 2018 09:11:42 CEST Simon Hausmann wrote:
>>>> Am 25.10.18 um 08:31 schrieb Shawn Rutledge:
>>>>
>>>>>
>>>>>> On 24 Oct 2018, at 17:09, Jason H <jhihn at gmx.com
>>>>>> <mailto:jhihn at gmx.com>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> In case it needs to be said-
>>>>>> I am AGAINST racism, sexism, bigotry, and all the other exclusionary
>>>>>> things. But I am also against people judging other people's code for
>>>>>> factors that have nothing to do with the code itself. I find that
>>>>>> adding
>>>>>> a value judgement of conduct to code to be intolerant. We had the
>>>>>> ideal.
>>> I am FOR inclusion. I want everyone to feel welcome here.
>>>>>> Everyone.>
>>>>> I agree. It seems to be about fixing something that isn’t broken, or as
>>>>> in that story in the Bible where the people came to a consensus that
>>>>> every other country around them had a king, so they should have a king
>>>>> too. Nothing good came out of it in any cases where we have seen this
>>>>> kind of illogic applied. “Most other big corporations have a deep
>>>>> hierarchy of management, with too much power concentrated at the
>>>>> top, and
>>>>> we want to be a big corporation, so we need to replicate that.” “The
>>>>> other lemmings are running away so maybe we’d better follow.” It’s not
>>>>> the open source way, which seemed to be working well enough already.
>>>>>
>>>>> If you give power to a committee of 3 people, they will probably
>>>>> abuse it
>>>>> eventually, misjudge, cause bitterness, create factions, and some
>>>>> developers will end up walking away. Seems predictable, doesn’t it?
>>>>
>>>> You claim that this is about fixing something that isn't broken. Your
>>>> statement that a committee will predictably and eventually abuse their
>>>> powers and misjudge is, I feel, a
>>>>
>>>> statement that is spreading fear, doubt and uncertainty, without any
>>>> evidence within the scope of this community.
>>>>
>>>>
>>>> On the other hand I am aware of at least one concrete case where the
>>>> behavior of a reviewer has caused a contributor (with a track record of
>>>> accepted patches, btw) to
>>>>
>>>> turn away from the project and even resulted in an email of complaint
>>>> sent to the community manager. The lack of tools, written understanding
>>>> and common agreement
>>>>
>>>> on what is good behavior resulted in that nothing happened at all and
>>>> the contributor in question has stayed away from the project since then.
>>>>
>>>>
>>>> I do think that this is the exception, but it is crucial that we have
>>>> the right tools and mechanisms in place when unlikely exceptions happen,
>>>> in order to deal with them
>>>>
>>>> instead of ignoring them. After having seen this with my own eyes, I am
>>>> convinced of that.
>>>>
>>>>
>>>> Whether it is a code of conduct or kindness guidelines - anything like
>>>> that is something that I welcome as an improvement.
>>>>
>>>>
>>>> Simon
>>> +1
>>>
>>> We do have a Code of Conduct at KDE for about 10 years now, and this
>>> hasn't
>>> led to abuse of power, suppression of free speech, racism against
>>> white people
>>> or whatever other nonsense people seem to attribute to CoCs nowadays.
>>>
>>> On the contrary, it gave us a solid foundation to act against the
>>> (very few,
>>> fortunately) cases of abusive behavior to protect our contributors. As
>>> Simon I
>>> have seen the damage such behavior can do, and therefore would also
>>> welcome
>>> tools/rules to be in place to deal with such situations.
>>>
>>> Regards,
>>> Volker
>> I fully agree.
>>
>> And btw, we have had a clear majority in favour of adding a CoC at the
>> Contributor Summit, and explicitly agreed that a group of people will
>> work on creating it. I’m happy we now have a first version, that we can
>> use as a basis for further discussions.
>>
>> Cheers,
>> Lars
>>
>>
>> _______________________________________________
>> Development mailing list
>> Development at qt-project.org
>> http://lists.qt-project.org/mailman/listinfo/development
>>
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
More information about the Development
mailing list