[Development] QUIP 12: Code of Conduct

[Jason H]

Thiago,

Here's a link that kinda puts it together: https://lulz.com/linux-devs-threaten-killswitch-coc-controversy-1252/ (Scroll to  "The Controversy" and the "rape apologist" Sage Sharp tweet)

I didn't realize this was a thing of "defeat". I have concerns, based on actual events, that I want resolved. 

I do respectfully disagree on whether or not an author is relevant to considering a work. In this case the author has a track record of attacking members in open source projects and arguing against meritocracy. Is the text good? There is a lot I agree with, but there are things in it that cross the line for me. I think we can come to an agreement, but not with invoking the Covenant in its current form. 


> Sent: Friday, October 26, 2018 at 2:35 PM
> From: "Thiago Macieira" <thiago.macieira at intel.com>
> To: development at qt-project.org
> Subject: Re: [Development] QUIP 12: Code of Conduct
>
> 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.