What another group does (was Re: Code of Conduct: Is it time?)

Hi,

I'm not much of a contributor to the project any more, but I thought
perhaps some information about what some other communities do might be
helpful.  (For those of you who don't know me, I used to be somewhat
active in this community until I got heavily involved in the Intenet
Engineering Task Force or IETF.  Alas, these days I seem to be
spending all my time on Internet politics.  I clearly made a bad
trade.)  Anyway, here's some stuff on how the IETF does this, in case
it is helpful.  This is a little long.  As the saying goes, I didn't
have time to write a short letter.

On Wed, Jan 06, 2016 at 08:50:40AM -0800, Joshua D. Drake wrote:

> It provides a sense of confidence to those who are not confident that they
> can come play in our playground and not be bullied. That is what every
> single code of conduct is about. There are a lot of very talented people in
> the FLOSS community that just don't like to work in areas that don't have a
> code of conduct.

I think there are a few different things that are coming together
under the rubric of "code of conduct", and it might be helpful to
separate them.

First, it's important to remember that many of the codes of conduct
actually arose from a problem that Postgres doesn't have.  Many
projects (Ubuntu is a good example) are actually communities that come
together around what is really a commercial enterprise (in Ubuntu's
case, Canonical).  So, some of the traditions of CoC happened because
companys' lawyers told them, "You need this in order to avoid getting
sued."  Because Postgres didn't grow up that way, it didn't have that
need traditionally.  But now that it is established practice, many
corporations won't allow their staff to participate in activities
without such a CoC, precisely because of the legal environment (this
is especially true in the US, of course).  Nevertheless, any project
with more than a handful of contributors pretty quickly develops norms
and generally enforces those, if only informally.

One kind of conduct is "acting in the community", which in virtual
communities like this one (and the IETF) mostly means mailing lists
and other such electronic exchanges.  Because of the way it's
organized (in working groups with chairs), the IETF has a way to deal
with misbehaviour of that sort: the chairs have the ability to
restrict someone's posting privileges on a WG's mailing list.  The
criteria are somewhat vague but it basically amounts to "stick to the
topic, don't be mean, and don't attack anyone personally."  In the
normal course off affairs, WG chairs enforce these things
(infrequently), and that's all there is to it.  Much of this is
codified in RFC 2418 and updates to it
(http://tools.ietf.org/html/rfc2418).  It's worth noting that, because
the IETF is made up of engineers, we have a lot of process documents.
Discussions around process tend to take a lot of engergy and sometimes
distract the IETF from its main work.  Some of us find this a little
vexing.

The overall acceptable conduct of participants is outlined in RFC 7154
(http://tools.ietf.org/html/rfc7154), from 2014, but the IETF adopted
its first such guidelines in 2001 (RFC 3184).

Sometimes we get people in the IETF who can't play nicely.  If it's a
problem across the IETF, we have a mechanism called "PR-Action" (for
posting rights).  It is outlined in RFC 3683
(http://tools.ietf.org/html/rfc3683).  We haven't had to use it very
often, but we have done and will probably have to do so again.  Also,
the main ietf@ietf.org mailing list has a sergeant-at-arms to try to
head off behaviour issues before they get out of hand.

Despite all those process documents, there have sometimes been worries
about harassment.  As a result, the IESG (basically, the managers of
the IETF) created an anti-harassment policy.  It's at
http://www.ietf.org/iesg/statement/ietf-anti-harassment-policy.html.
Part of the need for that policy came from issues outside the
community: while there were concerns about some of the behaviour
around the IETF (which has a real problem with gender and cultural
diversity, but had a bigger problem in the past), there was an
especially bad example of misbehaviour at a conference of another (but
related) community one year.  It motivated people to write down some
rules before things got really out of hand.  (Note: some argue that
the reason things didn't get as bad at the IETF as those reports
suggested was just that we had so few women participating in the IETF
that the population didn't support the scale of misbehaviour.  I'm not
trying to minimise the social problems that the IETF had.)  The IETF
has also created an "ombudsteam" (what an awkward word!) to try to
deal with any misbehaviour that comes up.  (You contact them at
<ombuds@ietf.org>.)

This brings up another issue that Postgres doesn't really have: some
communities (including the IETF) have official community meetings of
this or that sort, and there is a different kind of conduct for which
one might need a policy when humans physically in the same room are
involved.  Because Postgres meetings of various kinds are not usually
"project" meetings, but rather meetings organized by some group but
open to the community, the "meetings" part is not something the
Postgres community needs to have consensus about.  Instead, those
meetings have their own CoC.  This seems normal to me: the organizer
of a meeting should have such a code, and since the Postgres project
is in general not the organizer the project doesn't need to have a set
of rules about such meetings.

Finally, and separate from all of that, the IETF has a lot of rules
around intellectual property.  This is mostly because the IETF is a
standards organization, and so it publishes documents, and copyright
can be tricky under such cirumstances.  The good news there, of
course, is that Postgres doesn't really have this problem either,
because of the way a code contribution (which automatically gets the
PGDG license) gets distributed.  The IETF does have a code about
disclosing patent claims, however, and it might be another thing for
the Postgres project to think about.  We have a lot of these rules,
but if you want to have a look at how they work together you should
probably start at
https://www.ietf.org/about/process-docs.html#rfc.section.2.3.

I don't really have an opinion about whether the Postgres project
needs a CoC, but I will say that having some of these rules has helped
the IETF not be dragged into contentious discussions of acceptable
behaviour on some occasions.  (Whether someone's behaviour fails to
conform to the process documents, of course, causes its own arguments.
We have an appeals process for this, which would be hard to graft onto
other organizations.)  The other thing I note is that the IETF got
most of these documents because someone thought the problem was
important enough to write a draft proposal first.  As I said in a
recent IETF plenary, the organization works partly because at the IETF
you don't need anyone's permission to try something; you don't even
need forgiveness.  The worst that can happen is that people reject the
proposal.  It always seemed to me that the Postgres project worked in
a similar way, so I'd encourage those who think there is a problem to
be solved to make a scratch proposal and see whether it flies.  It's
always easier to discuss a concrete proposal than to try to figure out
whether something is a good idea in the abstract.  The shorter and
easier to understand the proposal is, I think, the more useful it is
likely to be.

I hope this was useful.  If not, please delete and ignore :)

Best regards,

A

--
Andrew Sullivan
ajs@crankycanuck.ca