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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development