[Development] QUIP 12: Code of Conduct

[Edward Welbourne]

Rafael Roquetto (25 October 2018 11:50)
> I understand this has already been set in stone,

I do not think you should take that for granted.  We do have a process
by which all contributors can contribute to the decision and should be
listened to, so that the resulting decision can be shaped by any and all
of us.

> and I am not here in the hopes this will change.

Speak and know you are heard.
Persuasion is possible.

> I would like to start by saying I fully agree with Shawn: what exactly
> are we trying to fix?

That sometimes folk have felt so intimidated that they give up on trying
to make a contribution; and that, were potential worse conduct to cause
distress to a contributor, we have no process in place that could give
them confidence that their distress will be respected and honest efforts
will be made to relieve it.  Various variations and permutations on
these themes may also be relevant; see Simon's mail.

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

This is why we takes care about designing things and invite review.
Which is exactly the process you see before you.

> Or is it proven technology?

See Volker's earlier post: KDE (among other communities) has been
using a CoC for some time and has (on the thankfully rare occasions
that it's mattered) found it does indeed work.  Proof enough ?

It's clearly possible to get a code of conduct wrong; we need to take
care to avoid making those mistakes.  It may be possible that a code of
conduct wouldn't be any help in *this* community, 'though it has been in
diverse others; if you believe that is the case, make the case for it.
Some of us, at least, shall listen.

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

Nothing is ever so simple: projects that fail to be welcoming to
contributors get fewer contributions.

> I find it extremely off-putting to see that the Qt project is
> embarking in this sort of politics

I'm not sure why you see it as politics, or what you mean by "politics".
It's part of governance, ensuring we do have oversight of a process that
surely does happen informally anyway - if I see another reviewer being
(IMO) rude to a contributor I have been known to take that up with the
reviewer, on my own initiative; but I might be out of line (I have no
expertise in this area) in doing so, or might not go about it in the
most constructive way; and I have no authority, so the reviewer might
not pay attention to my poking.  Having a Conduct Committee who
(hopefully) have some clue about how to diplomatically invite someone to
be gentler to their peers would be an improvement over my informal (and
arguably also rude) attempt to deal with what I perceive as rude; it
might also ensure that a consistent standard is applied for what *does*
constitute rudery.

> - 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 have seen a contributor despair at a reviewer, who they felt was being
unfair, and give up on contributing.  I have felt similarly about one
reviewer, from time to time.

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

Note that some folk aren't going to get past that.
The distinction between seeming rude and being rude is rather thin.

You and I have the confidence to stand up to rudery and get past the
initial impression to get constructive results despite it, but some folk
do get put off by it and we do lose their contributions as a result.
I have seen this happen.  IIU Simon correctly, he has too.

> until I realized that: 1) it was just their modus operandi;

That may be: but if they learn to be at least somewhat friendly about
it, they're less likely to scare off contributors.  There should be no
need for someone to tolerate intimidating conduct before they can get
the good that is in their code recognised and, after any needed
improvements, put to use.

> 2) at the end of the day, their comments made sense and improved my
> code;

That is nice, but surely it would be better if they could steer you
towards those improvements *without* making you uncomfortable on the
way.  In particular, for some potential contributors, that makes the
difference between getting their contribution in and giving up; and a
kinder process might leave more contributors eager to come back with
further contributions, where an intimidating one is apt to discourage
them from attempting further contributions.

> 3) they were not butt hurt when roles were reversed.

I do not find that an adequate excuse.  Certainly, if they *were* upset
they'd be guilty of hypocrisy.  The fact that they can cope with abusive
treatment isn't any kind of justification for dishing such treatment out
to others.  It is better to actually be considerate towards those whose
code one reviews.

I remember school-mates being singularly rude to each other all the
time.  Notably, on the football pitch, they threw about a barrage of
insult, demand and blame - at their own team-mates, note - that made it
unpleasant to play with them.  In competitive leagues, being a small boy
(until late in my time at school) and not much liked by the ones who got
to pick teams, I got to be assigned to a team consisting mostly of boys
a year younger; who, by virtue of my age, treated me with at least
somewhat more respect; so I was quite happy to not be picked to be in
the team of my peers, though I got dragged in enough times to see how
they treated one another (and me, but that's how they always treated
me).  Eventually, once I'd grown and become rather good at what I did,
my peers felt they should condescend to let me play in their team; but I
declined, because I did not enjoy playing in the abusive environment
they generated.  This left me in a team of (mostly) younger boys, so I
had to be captain, despite that being normally a forward's job, not a
centre-back's.  My first rule was that my team were not allowed to be
rude to one another or blame each other for things that didn't go our
way; we were on the playing field to get some exercise and have some
fun; if we could also win, so much the better.  This soon lead to a team
that was enjoying playing and worked together better than most of the
teams of our peers that we came up against.  Despite being "less able"
players in the fairly objective terms of various teachers, this team
beat teams of "better" players because they were crushing their own
team-mates' morale, while we were having fun (at their expense).
That included sincerely congratulating them when they played well.

In an abusive environment, the thick-skinned bullies rise to the top and
keep the place abusive, so that their kind keeps on winning.  In a more
respectful environment, folk who treat others with respect gain respect
and, feeling respected, are more able to deliver useful results.  I
think this community is considerably closer to the latter than the
former, but the exact experience you describe is a shadow of the former,
that I'd gladly banish.

The questions I want addressed are:
* Will a CoC help ?
* If so *what* CoC do we want ? and
* What surrounding process will lead to respectful resolution of such
  conflicts as do arise around the CoC ?

> Communication/criticism just like this is unambiguously
> straightforward and I *personally* prefer it this way.

Would you prefer it yet more if you were treated more gracefully, even
when someone is pointing out your errors ?

	Eddy.