[Development] QUIP 12: Code of Conduct

Alexey Andreyev yetanotherandreyev at gmail.com
Thu Oct 25 13:28:07 CEST 2018


Hello! Young Qt fanboy, who worried about the future of the project:

What problems are CoC trying to solve?
Abusive behaviour?

People are not social angels at all.
But how many situations of problematic behaviour at the Qt project do
we have with current terms?
When it's ruined some tasks we still could not solve? Could it be
compared to the successful situations?
Is the relative number a zero, one-two, ten, hundred?
Is the value grows, fixed or decreases somehow? Are there some
internal and external reasons?

Are CoC helping for other similar projects? Is there any research?

I agree we should have defined common values as a community. And I
want to contribute too.
I guess we should think twice at least about new fancy CoC. I'm happy
that nobody is forcing hard it for now.
I like the discussion at codereview.

>From my point of view, some rude words could be filtered automatically
or semi-automatically if we want to
and it's not a huge problem. So let's skip all the cases when it's
just about swearing for now.

Let's focus on situations, when conflict is about the meaning of the sentences.

It's the case about ideology (a system of ideas and ideals, something
opposite to science in some terms, but something completing it to form
a community). From my point of view, our speech probably could not be
ideology-free.
And it's not some bad thing we should get rid of, ideology instead
should help community to develop and survive as a single whole.
Some "let's be free from well-defined ideology" is just yet another ideology.

So about ideology point CoC is trying to provide: I could see it for
now as "let's forbid "non-constructive" negative feedback and everyone
will be happy" (feel free to correct me).
My problem with that is that focusing on "negative feedback" as
absolute evil ("non-constructive" is practically not the key, because
it's not well defined).

I guess we could all agree that some "sweet" feedback could ruin the
community as easy as "direct offensive" feedback, if not faster. So do
we really want to somehow restrict negative side of feedback without
limiting positive? Is it practically possible to do it for the health
of the community?

Feel free to criticize me or skip a message if it's inappropriate. And
thank you for your time!
Sorry for a spelling, I'm not a native speaker.

2018-10-25 10:58 GMT+03:00, Lars Knoll <lars.knoll at qt.io>:
> 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
>
>



More information about the Development mailing list