[Development] QUIP 12: Code of Conduct

[Jason H]

> Sent: Thursday, October 25, 2018 at 11:13 AM
> From: "Edward Welbourne" <edward.welbourne at qt.io>
> To: "Jason H" <jhihn at gmx.com>, "Mitch Curtis" <mitch.curtis at qt.io>
> Cc: "Qt development mailing list" <development at qt-project.org>
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> Jason H (25 October 2018 16:43) contributed:
> 
> Mitch, you wrote:
> >> To me it seems like you guys are saying:
> 
> >>> "I don't care if this person treats me like crap because they sure
> >>> can code."
> 
> >> I'm happy for you if you've gotten this far in life and decided that
> >> you like being insulted in exchange for someone reviewing your code
> >> (or even just asking a question on IRC), but personally I do not like
> >> it. I'm more than capable of standing up for myself, but other people
> >> who feel the same way may not feel comfortable speaking out.
> 
> > I do not want to contemplate the emotional state of being of the
> > author when reviewing and leaving comments on gerrit.
> 
> I do want to encourage you to think about how you phrase your criticisms
> of others' code; in particular, by "contemplating the emotional state
> of" an author being so criticised (this is what empathy is about).
> 
> > Many times when I an giving technical feedback, I have been told "[I]
> > sound harsh." I'm just being factual.
> 
> Two ways of saying the same thing may have identical information content
> (i.e. they're both "just being factual"), yet have different emotional
> content.  One does not have to bend over backwards to treat folk gently:
> it is enough to just think about the ways of phrasing your feed-back
> that respectfully invite them to notice their error rather than just
> telling them they're wrong.  With practice, it comes quite naturally to
> think in terms of "what can I say that will give this person the same
> understanding I have" rather than just proving that you know better than
> them.
> 
> > I never call into the matter anything about the person,
> 
> There are more ways to wind people up than direct ad hominem attacks.
> Phrasing may hint that you think no-one but an idiot would fail to
> notice the thing you happen to know, that they don't.  You might not
> even intend that hint, but it may yet come across.  In particular, if
> you *do* think that only an idiot would fail to see what you're pointing
> out, please pause to remember that contributors to Qt seldom actually
> are idiots and think about what might lead a perfectly reasonable and
> smart person to be unaware of the thing you are so familiar with that
> you take it for granted.

As a personal strategy I completely agree with you. However I've been at this for 20 years and it's not anything I've made significant progress on. I do not want to offend anyone, though I'm sure I have, inadvertently. I give you my word that I'm not going to verbally abuse anyone. I am continually humbled by the people in this community. They are brilliant. I often learn from being wrong on this and the other Qt lists, so I recognise this community has people of all different levels of ability. I still do however take issue with the idea that I am somehow responsible for someone's reaction to a factual observation or suggestion. It creates a slippery slope of judgement, and it creates a concern that maybe I'll be approached and be told to use kinder words, even when no unkind or inaccurate terms were used.  I do however recognize that oser-use of violent profanity could turn people away. I do not know how to strike a balance. This is why I prefer to keep it all about the code. 

> > but some people still do get butt-hurt when you talk about their code
> > negatively because it is their art. They then can project that
> > criticism of the code onto themself. This is nothing I want to be in
> > the position of being responsible for. As long as my comments are
> > accurate and not unduly harsh, they are (or at least should be deemed)
> > appropriate.
> 
> Leaving aside whether this should or shouldn't be covered by a code of
> conduct, that is an attitude I feel I have a duty to challenge.  I am
> quite capable of forgetting that others can't keep up with some of what
> comes easily to me; and I have had decades of colleagues calmly pointing
> out to me that perhaps what's obvious to me might not be known by
> everyone else.  Eventually I learned to stop and think about whether
> what was obvious to me was, in fact, obvious to everyone else.  It turns
> out that, with the vast breadth and complexity of the world of software,
> that there are many of us who are used to taking for granted things that
> others don't know about; and, unless we stop to remind ourselves that
> those we're talking to might be less familiar with the matter, we end up
> being quite rude without even thinking about it.  It is, indeed, the not
> thinking about it that *is* rude.
> 
> I was annoyingly pedantic until I learned that, in fact, communication
> is at least as much (and, when done competently, more) about the other
> person's understanding than mine.

I would argue that taking criticism about code is a skill that *MUST* be learned for every developer.  Giving effective criticism is also a skill to be learned by every developer, and is just a good life skill in general. How do we split the difference? Or, how we determine who is inappropriately offended? Likely when such situations occur it'll be split blame, because the reviewer *could* have used better language. But then you're effectively condoning the lack of skill in taking criticism. Can criticism be too harsh, surely. But it gets us onto a slippery slope and I prefer 1s and 0s.

> > Next, we have the notion that the CoC was somehow agreed to at the
> > Contributors summit.
> 
> Well, those at that meeting in the CS agreed to move forward with it.
> Ulf has, quite properly, done their bidding.  He has also, quite properly,
> publicised this on the list *precisely* so that those who can't make it
> to Contributors summits, or at least missed that one, or were in one of
> the other parallel sessions at the time, have the chance to express their
> views on the matter.  If nothing else, those who chose to attend that
> particular session, even among those at the CS, shall have been to some
> degree self-selecting as a group more likely to favour a CoC.
> 
> So please don't interpret this as a steam-rolling of a CoC regardless of
> what folk want: it's the next step in a process started by some folk who
> did call for it; at this step, we get to see how the rest of the
> community feels about it,

I have no beef with Ulf, or anyone who wants a CoC. Clearly, he doing his duty. I do feel steam rolled as this was never put to the community at large and those in attendance were not duly elected representatives. It feels steamroller-ish because it seems like it's a foregone conclusion that we'll have one. Until you mentioned it just now I thought that ship had sailed. Why work on wording of it's not even a thing to happen? The cart is before the horse. The process should go[/have gone] like this:
1. At Summit, take a vote if this is something to be raised to the larger community.
2. Have the larger community vote on it using general terms as to what the goal would be, what it would contain.
3. If that passes move to specific phrasing.

I am not against adopting measures to ensure that people who are abusive can be removed. As a matter of fact last night I was looking at stuff on community engagement that having a moderation is a good thing, but not entirely effective. In fact to break it down: rumination is .43** correlated with withdraw, moderator intervention is -.13** correlated with withdraw; ** p < .005. Here, rumination is 3 times more likely to produce withdraw than having a moderator. But still, I think it's good thing to document what abuses, if any, will get you removed from the community and how that process works. Such agreements would have to be shown as a click-through when joining a Qt property (mailing list, jira, gerrit, etc.) I'm still against it in general because it introduces slippery slopes and politics. In order for me to consider endorsing any such community conduct standards, it would have to have the following features:
1. No consideration given for off-Qt property actions. (social media sites, email, etc)
2. A non-standing Committee that exists for specific incidents, who
2a. members are chosen at random for each incident
2b. can somehow guarantee the confidentiality of evidence and proceedings, to protect the accuser and accused.
3. Limits slippery slope aspects the fewest possible aspects, and when on a slippery slope aspect, constrains them to their most boolean limits, construed in favor of the accused. 

Anything more will itself be a vehicle for abuse.

I really, really hate that we've brought politics into this community. Likely, your opinions of me have changed. I just wanted my presence here to be about Qt. But now I've had to reveal my politics which will open me to judgements not related to my technological contributions. 

I realize the initial vote occured before that whole Linux ordeal started, I hope we can learn from what is currently playing out with Linux and avoid that.