Fwd: Ubuntu Code of Conduct: omissions and suggestions

Melissa Draper melissa at meldraweb.com
Fri Apr 8 17:37:54 UTC 2016


resending to list, sorry matthew

---------- Forwarded message ----------
From: Melissa Draper <melissa at meldraweb.com>
Date: Fri, Apr 8, 2016 at 10:24 AM
Subject: Re: Ubuntu Code of Conduct: omissions and suggestions
To: Matthew Paul Thomas <mpt at canonical.com>




On Fri, Apr 8, 2016 at 4:02 AM, Matthew Paul Thomas <mpt at canonical.com>
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Elizabeth K. Joseph wrote on 07/04/16 18:49:
> > ...
> >
> > This has been on my mind a lot since Sarah Sharp's keynote at
> > SCALE14x (where we had the UbuCon Summit). It's a great talk,
> > video here: https://www.youtube.com/watch?v=ZCvK_7FagGE&t=31m5s
>
> Thanks. I had come across a similar post from her earlier.
> <http://sarah.thesharps.us/2016/01/25/code-of-conducts-warning-signs/>
>
> > During part of it she suggests that you shouldn't write your own
> > CoC and enforcement policy and that the following orgs and people
> > can help with this:
> >
> > Safety First PDX: http://safetyfirstpdx.org/ Ashe Dryden:
> > http://www.ashedryden.com/ Frame Shift Consulting:
> > http://frameshiftconsulting.com/
> >
> > I know we've "been fine" always writing our own (indeed, ours was
> > the first in an open source project AFAIK), but I think it's worth
> > considering if we want some help from experts :)
>
> True. On the other hand, Ubuntu is unusual in that it’s a vast
> project. It’s broad in organization: there are several Team Councils
> as well as the Community Council. And it’s broad in scope: discussions
> like “Does the Browser app’s Private Mode satisfy its use cases” or
> “What kind of maturity/age ratings should the Ubuntu Store have” would
> necessarily involve uncomfortable topics that a smaller project’s code
> of conduct can easily exclude altogether.
>
> >> 1.  No descriptions of common but unacceptable behavior. This
> >> means, for example, that the Ubuntu IRC Council has had to
> >> provide their own descriptions, even of things that don’t apply
> >> just to IRC. <https://wiki.ubuntu.com/IRC/Guidelines>
> >
> > This may be an interesting one to dig into, but I'm not sure how I
> > feel about it. I worry that giving examples can provide a framework
> > that people feel they can wiggle out of. But again, I'm not one of
> > the experts, so there may be a great deal of value here.
>
> The extremely popular Contributor Covenant starts with five “Examples
> of behavior that contributes to creating a positive environment” and
> five “Examples of unacceptable behavior by participants”. It’s clear
> that they’re just examples, not an exhaustive list.
> <http://contributor-covenant.org/version/1/4/>
>

I'll add that our "list of examples" is not as helpful as it may seem and
despite it being in place for years, it never really has been. It's really
not actually clear to everyone. Some people genuinely have problems
realizing the difference between stating a position, and hitting the point
of repetitiveness and hostility, especially when someone's position on a
topic is hostile in and of itself. Time is frequently spent explaining to
people the concepts of "being hostile", "baiting" and so forth. The
conversations are rarely fruitful, result in much frustration on both
sides, and there is never a winner when we're choosing between a. excluding
someone who has genuine social issues and b. allowing disruptive behavior.
I personally always feel terrible when someone ends up excluded for being
literally unable to grasp things in a way we take for granted. People who
fall into this classification are disproportionately represented in digital
communities.

The toxic people who decide they get to engage in negging while claiming
they should be able to do so "because I help people!" or go all rules
lawyer to wiggle out of stuff however I have little regret telling to go
elsewhere. Sometimes this escalates silentlyThere however has been
reluctance to do this in the past and we're working on dealing this
attitude.

Figuring out to which group someone actually belongs is difficult.

>> 2.  No reporting instructions with contact information. This is
> >> perhaps the most glaring omission (and what motivated me to write
> >> today).
> >
> > This is a good point. I was very vocal[0] back when we had in
> > person UDS that various types of contact information was made
> > available on the anti-harassment page for the event, but I never
> > followed through in our written document online. I think adding a
> > section about contacting the CC would be great.
>
> I’ve found a “Reporting a Community Problem” page on the wiki, but it
> was last updated in December 2009. Is it still accurate?
> <https://wiki.ubuntu.com/ReportingCommunityProblems>
>
> >> 3.  No information about enforcement. Version 1.0 said “the
> >> Ubuntu Community Council will arbitrate in any dispute”, with
> >> 1.1 adding “Ubuntu governance bodies”, but 2.0 removed both of
> >> these. <https://launchpad.net/codeofconduct> Matthew Garrett made
> >> a start on defining the enforcement process in 2007, but it
> >> didn’t go anywhere.
> >> <https://wiki.ubuntu.com/CodeOfConductDisputeResolution> The
> >> current process may be precise and well-known to the Community
> >> team, but defining it in the Code itself would be much more
> >> reassuring to potential reporters.
> >
> > Good point, this should be addressed.
>
> So … What is the current process? The above page says “a discussion
> will occur in the bug report to work towards a solution”, but it gives
> no clue of who will be involved, how quickly, how publicly/privately,
> or what the possible outcomes may be.
>
> > ...
> >> 5.  Needless bureaucracy of “signing” the Code
> >
> > This has been something we've been concerned about for years. I
> > believe the main holdup was that it's all done in Launchpad and
> > Launchpad has been feature frozen for years, essentially bounding
> > us to use what we had with GPG signatures, and having few other
> > options.
> >
> > My hope is that we can finally find a solution so we can move past
> > this, perhaps even moving the process off of Launchpad if that
> > continues to be a blocker.
> >
> > ...
>
> Would anything bad happen if we removed the requirement to sign the
> Code for any reason, and expected everyone to follow it regardless?
>

Who are you aiming for here?

Many people's early interactions with the community are still when they are
seeking help in the consumer->contributor pipeline. They aren't always in a
great mood. In fact frustration, flailing and fury are more typical. Their
obligation to play nice is certainly not something they appreciate being
informed or reminded of. It seriously doesn't convince angry hostile people
to be calm and polite. They didn't come for community, they came to get
their expensive piece of hardware working again.

ToC may well be a very common practice, but it also commonly enrages people
further. We have a link to the guidelines in the topic of #ubuntu, and
every join is greeted by chanserv with the in-channel message "Use of this
channel implies acceptance of terms at
https://wiki.ubuntu.com/IRC/TermsOfService" so already by using the IRC
channels that they've "agreed" to behave by the code of conduct and our
guidelines. We often try get people to merely read the guidelines in
exchange for their first infraction being waived, like a get out of jail
free card. A surprising number of people refuse the offer.


>
> - --
> mpt
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iEYEARECAAYFAlcHj7kACgkQ6PUxNfU6ecoOGwCePngwK0mY9zYtqDe3CdAfNzVH
> 36IAoMn11i/v1Vc9vDbrx02ehBOaOJzo
> =A9kB
> -----END PGP SIGNATURE-----
>
> --
> Ubuntu-community-team mailing list
> Ubuntu-community-team at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/ubuntu-community-team
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/ubuntu-community-team/attachments/20160408/5d18dcdc/attachment-0001.html>


More information about the Ubuntu-community-team mailing list