[Development] QUIP 12: Code of Conduct

NIkolai Marchenko enmarantispam at gmail.com
Fri Oct 26 20:40:14 CEST 2018


>  Coraline's intentions are irrelevant. What matters is the text: is it
good?

I have to disagree. As I see it: she has spent considerable amount of time
drafting the exact text to allow her to bully projects.
Have you spent as much time analyzing all of the potential pitfalls she may
or may not have inserted into this document?
She's a malicious person and not second guessign her Code is a mistake.

Yes, indeed, is the text good? This has to be analyzed: in depth. And I
would still probably avoid using hers.

On Fri, Oct 26, 2018 at 9:35 PM Thiago Macieira <thiago.macieira at intel.com>
wrote:

> 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/6e451219/attachment.html>


More information about the Development mailing list