[Development] QUIP 12: Code of Conduct

Alexey Andreyev yetanotherandreyev at gmail.com
Fri Oct 26 09:44:57 CEST 2018


Hello! :)
The CoC is a lie. From my point of view, some of the current intentions at
least.

I'm hesitating a bit, that I'm so loud. I'm doing this to prevent problems
at the community, trying to find bottlenecks and provide better solution
for us.

> The rest should be in the CoC text itself and how it empowers the
resolution committee to make its decisions as well as any
checks-and-balances on the com committee itself.  Specifically, the CoC
should not be used to discriminate against one's political views any more
than on another's sexual orientations. And what you do on your private time
is your own business.

I want to contribute: to accept that, we have to define "private time"
meaning in a such public place as the web. Is personal blog page posting a
private time?

Secondly, the idea about "non-discrimination" and being free from shared
political or other values (at least minimal) could be easy perverted as
restriction to even talk about the defined topics. It could be used against
the community false-defining some sentenses as restricted. And we have
real-life examples of this. So we probably need at least minimal shared
values if we are proposing some CoC, not just undefined "free from
discrimination".

> We can also work with that person to find a compromise solution. I find
it hard to believe we couldn't, if that person is willing to see the other
side of the coin. And I speak from experience on that.

I agree we should work together on shared values

> 3) how do we prevent ill side-effects and abuse? One ill side-effect
would be the turning away of important contributors who feel that the
adoption of the CoC stands in the way of their participation. But please
note that has not happened to any significant manner in any of the big Open
Source Projects that have adopted CoCs. That includes the Linux kernel:
despite what you may have heard in the media, the kernel maintainers and
Linus himself subscribe to the new CoC and Linus has returned to
development.

Looks like it doesn't happened yet to open source projects, yes (feel free
to correct me). Just want to add that proposed CoC raised the questions at
least in case of the kernel project and we should carefully research
negative impact too to prevent worst results

> 2) why not let the code rule? [...] So clearly code is not enough.

I agree. I guess the idea why some people focusing on the code it's because
the code is better defined and verifiable at least. And some people are
probably searching for metrics how to check CoC is positive for community
development not negative. If we don't provide well-defined document, it's
probably makes no sence to include undefined with visible dangerous
problems. That's why some probably prefers KDE's version more.

> 1) if it ain't broke, why fix it? [...] We don't want to lose them or
their contributions. Think of the CoC as preventive maintenance: you don't
do it because it's  broken. You do it so it *won't* break in the first
place.

I probably agree. And want to add we should be very careful.

> But the CoC was adopted, with no ill effects.

I guess global situation changed since that. And what if we compare the
number of public conflicts at the world and dates when undefined rules
about that was accepted at big companies? And it's not about just example
with Theodore Ts'o. Look at the cinema world. We should be careful not to
create rules that could be just a backdoor for external companies to force
thier expansion ideas not focused on helping at all. I agree we should
think about others and help each other, and could try to build shared
values document. The questions is about implementation.

> So I want to say this first: Intel does support Open Source Projects
adopting Code of Conduct as well as actions leading to increasing access
and diversity of ideas, hopefully leading to improved code. We also
particularly like the Contributor Covenant text.

My idea was to show that "diversity of ideas" is just yet another idea. Not
all the ideas is clear and positive by default.

"What's you favourite idea? Mine is to be creative..." (from "Don’t Hug Me,
I’m Scared")


пт, 26 окт. 2018 г., 8:15 Thiago Macieira <thiago.macieira at intel.com>:

> On Wednesday, 24 October 2018 00:17:09 PDT Ulf Hermann wrote:
> > Hi,
> >
> > regarding our earlier discussions on a possible Code of Conduct, here as
> > well as at the Contributors' Summit 2017, I've pushed a QUIP with the
> > necessary rules and definitions:
> >
> > https://codereview.qt-project.org/243623
>
> Hello Ulf and everyone else on this thread
>
> I've posted a few comments here and there relating to the process of
> adopting
> anything in our community, but I haven't yet voiced my opinion on this
> subject. This email is it.
>
> Note that even though I am speaking for myself, I understand my opinion
> reflects on my employer. So I want to say this first: Intel does support
> Open
> Source Projects adopting Code of Conduct as well as actions leading to
> increasing access and diversity of ideas, hopefully leading to improved
> code.
> We also particularly like the Contributor Covenant text.
>
> I am also personally in favour of adopting a CoC and I support adopting
> either
> the Covenant text or KDE's. Both are fine to me. Another good one is
> Mozilla's[1], which the SQLite developers have just adopted too.
>
> In fact, I was there 10 years ago when KDE decided to adopt something.
> Back
> then, I was also of the opinion that we shouldn't need anything. The KDE
> community had always been a welcoming one: in my first Akademy, I was
> greeted
> by people I had only met online as an old friend. Moreover, the KDE
> community
> had always resisted any kind of formal structuring of anything, which led
> to
> the Technical Working Group being created and disbanding in 2006. Even
> today,
> the KDE e.V. takes great steps to make sure it is never seen as a ruling
> body.
>
> But the CoC was adopted, with no ill effects. I do not have direct
> knowledge
> of where they had to intervene, if at all, but I'm told it has happened.
> More
> importantly, I have also grown as a person since then. In a particularly
> telling moment, when a female colleague here in the office (located in a
> very
> affluent, liberal and progressive part of the US) once asked my opinion on
> the
> Python Donglegate incident and explained to me the reason why she
> interpreted
> it the way she did, I realised how my worldview was so very different from
> hers. I've come to understand how little things that did not bother me
> were
> highly offensive to her.
>
> I've seen basically three questions asked by the skepticals to this
> proposal:
>
> 1) if it ain't broke, why fix it?
>
> To put it simply: the CoC has as an objective make sure the community is
> always welcoming and inclusive. People have a limit on how much hostility
> (intended or not) they're going to put up with. If they reach that limit,
> they're going to simply avoid it and that can be anywhere from avoiding
> contributions to certain parts of the code to stopping contributing
> altogether
> (or worse). We don't want to lose them or their contributions.
>
> Think of the CoC as preventive maintenance: you don't do it because it's
> broken. You do it so it *won't* break in the first place.
>
> 2) why not let the code rule?
>
> Code does not exist in isolation and the Qt Project is not a set of files
> in
> Git. The Qt Project is a community that maintains that code, so we need
> rules
> beyond code. We have contributors who don't contribute a lot of code, but
> that
> does not make them any less important members of the community.
>
> Besides, any commit comes with a commit message. Any review comes with
> feedback and there are few that are simply "+2" with no text. We want good
> code, improving Qt and for that we need to interact with one another.
> Moreover, the major architectural issues are not discussed in code, but in
> prose via email.
>
> Finally, being good at C++ is not an excuse for being a jackass. No one
> should
> get a pass because they're experts at something. We can't make the cold
> calculus that "person X's productivity is worth 10 new contributors so we
> will
> allow X's behaviour to turn away 10 contributors". What happens on the
> 11th?
> And what if one of those turned out to be amazing after a few months?
>
> So clearly code is not enough.
>
> 3) how do we prevent ill side-effects and abuse?
>
> One ill side-effect would be the turning away of important contributors
> who
> feel that the adoption of the CoC stands in the way of their
> participation.
> But please note that has not happened to any significant manner in any of
> the
> big Open Source Projects that have adopted CoCs. That includes the Linux
> kernel: despite what you may have heard in the media, the kernel
> maintainers
> and Linus himself subscribe to the new CoC and Linus has returned to
> development.
>
> We can also work with that person to find a compromise solution. I find it
> hard to believe we couldn't, if that person is willing to see the other
> side
> of the coin. And I speak from experience on that.
>
> The rest should be in the CoC text itself and how it empowers the
> resolution
> committee to make its decisions as well as any checks-and-balances on the
> com
> committee itself.  Specifically, the CoC should not be used to
> discriminate
> against one's political views any more than on another's sexual
> orientations.
> And what you do on your private time is your own business.
>
> [1] https://www.mozilla.org/en-US/about/governance/policies/participation/
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
>   Software Architect - Intel Open Source Technology Center
>
>
>
> _______________________________________________
> 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/20181026/9c64313a/attachment.html>


More information about the Development mailing list