[Development] QUIP 12: Code of Conduct

NIkolai Marchenko enmarantispam at gmail.com
Thu Oct 25 12:00:44 CEST 2018


> And btw, we have had a clear majority in favour of adding a CoC at the
Contributor Summit

It seems very wrong to make such decisions at conventions where only a
small part of the contributors can participate.
Especially for something as big and divisive

On Thu, Oct 25, 2018 at 12:52 PM Rafael Roquetto <rafael at roquetto.com>
wrote:

> 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...
>
> 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).
>
> 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?
>
> 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.
>
> 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.
>
>
> - 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20181025/1ecaf558/attachment.html>


More information about the Development mailing list