[Development] QUIP 12: Code of Conduct

[Alexey Andreyev]

> I personally think those situations explain why we need a CoC in the
first place and why the judgment on such situations is very subjective,
best left to humans, not to a script. And the deliberations should not be
in a public forum, like a GitHub issue.

If mentioned situations best left to humans, what is current CoC for? If
deliberations should be limited, who could have access to it?

> Isn't it showing that it's *working*?

I guess not, not the current version of the CoC at least. Communities are
spending resources instead of working on other tasks. If discussed
situations be left to humans in the end with current document, we could
just state simple one-liner instead: "be conscious and think about future
consequences", -- to minimize CoC problems at least.

As I said previously, I agree we should work together on a better version.
I guess Qt people could do it.

пт, 26 окт. 2018 г. в 21:35, Thiago Macieira <thiago.macieira at intel.com>:

> On Friday, 26 October 2018 09:48:11 PDT Jason H wrote:
> > My fundamental problem about the Contributor Covenant[1] was initially
> and
> > solely the fallout from the Linux Kernel fiasco. But then I learned that
> it
> > was drafted by Coraline Ada Ehmke, who sought to have a contributor
> removed
> > [2] from a project preemptively. The contributor did nothing wrong with
> > respect to the project or the project's community.  She constructed a
> claim
> > of "transphobia" based on a tweet the contributor wrote in no way
> relating
> > to the project at hand, and slandered the project for not expunging them.
> > My mind is made up: the Contributor Covenant is a tool of oppression.
>
> First of all, the kernel adoption of CoC was not a fiasco. All the
> negative
> emails you may have seen came from people who are not contributors, often
> their first and only email to the mailing list. Despite what Eric Raymond
> has
> said, revoking the copyright licence for GPL just cannot be done -- it
> would
> be against GPL's spirit.
>
> Coraline's intentions are irrelevant. What matters is the text: is it good?
>
> But if your mind is made up, kindly refrain from trying to convince others
> to
> change their minds too. This is a two-way street and you're only welcome
> to
> argue your point if you're willing to admit defeat too.
>
> > The specific sentence in the Covenant is:
> > "This Code of Conduct applies both within project spaces and in public
> > spaces when an individual is representing the project or its community."
> >
> > However, despite being the author of the Covenant (2014), she found it
> > appropriate to attack someone who was clearly not operating in a project
> > space or representing the project community (2015). We now have two
> > examples - the linux Kernel and Opal project, that after CC was enacted
> > that calls for removal of members based on past unrelated tweets went
> out.
> > One of the problems its politics and political climates change over time.
> > Expressing what is not political at one point in time may become
> political
> > in subsequent years. People's minds also change over time.
>
> What is the kernel example? Who was forced out, or attempted to?
>
> > I urge you to read link[3] below and see if we want that kind of
> attention.
> > It summarizes what happens when the CC has been adopted by other
> projects.
> >
> > [1] https://en.wikipedia.org/wiki/Contributor_Covenant
> > [2] https://github.com/opal/opal/issues/941
> > [3]
> https://linustechtips.com/main/topic/974038-why-the-linux-coc-is-bad/
>
> I have.
>
> The proponents of the removal were arguing that having such a person as a
> project leader is poisonous to the project, *regardless* of the fact that
> it
> was done in private time, because it would turn away potential new
> contributors as they didn't want to associate with such a person. This is
> an
> extreme situation, indeed, and one that the CoC committee should be able
> to
> make a judgement on: which way is the project best served?
>
> Anyway, given that the request to get the maintainer removed was not
> accepted,
> how is that a failure of the CoC? Isn't it showing that it's *working*?
>
> I personally think those situations explain why we need a CoC in the first
> place and why the judgment on such situations is very subjective, best
> left to
> humans, not to a script. And the deliberations should not be in a public
> forum, like a GitHub issue.
>
> --
> 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/54e9c8f6/attachment.html>