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@xxxxxxxx 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@xxxxxxxx>.) 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@xxxxxxxxxxxxxxx -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
