Adopt a Code of Conduct

[jcrist]

As part of becoming a NumFocus project (#1) we'd need to adopt a Code of Conduct (CoC). A few examples:

• Contributor Covenant (used by many projects)
• Python Community CoC
• Jupyter's CoC
• Django's CoC

[pitrou]

I would suggest something lightweight such as the Python (really PSF) CoC.

[mrocklin]

One way in which these codes differ is in the extent to which they enumerate specific classes of acceptable and unacceptable behavior. As I see it the benefit to non-enumeration is that it has longevity and also doesn't allow for people to say "but my behavior wasn't specifically listed". As I see it the benefit to enumeration is that it welcomes people who might feel specifically at-risk for a particular type of bad behavior, and it also makes it easier for community maintainers to point to the code in the case of an infraction. "You clearly said X, which is clearly listed on our code" rather than "You said something that was offensive as I interpret it".

Given the short lifespan of software projects (Python excluded) I'm somewhat inclined towards more specific enumeration of common forms of harrassment today. I don't expect this list to change significantly over the lifetime of the project, which I anticipate as lasting no more than 10 years.

I like the PSF CoC, but I like the explicit style of the Contributor Covenant a bit more. This is mostly because if someone makes crude statements like a "yo momma's so fat that ..." joke or "that's gay" then I can very clearly point to a line in the CoC and have a very short discussion, rather than have to go back and forth about what should or should not be considered offensive within this community.

To be clear, I apologize using the statements above, both of which I consider to be offensive and not acceptable within this community. It's just very useful to have a couple concrete examples when discussing this topic.

[ogrisel]

+1 for Contributor Covenant . I find it a good compromise between lightweight and explicit enough.

[jcrist]

I also vote for the Contributor Covenant.

How should we as a community go about making a decision here? Do we want all org members to weigh in in a vote, or should we just move forward once a few people agree unless someone explicitly disagrees?

[mrocklin]

How should we as a community go about making a decision here?

I recommend that we wait for a while so that people can express their thoughts. My hope is that we eventually come to concensus in this case, but only after having discussed it for a while. Having this discussion within the community may be as important as adopting the document itself.

Other projects presumably saw the Contributor Covenant before and decided to modify it based on their experience. I encourage people who haven't yet spoken up to read some of the other documents, compare them a bit, and speak up if anything strikes them as interesting.

[pitrou]

One thing that bugs me with explicit lists is the following:
jupyter/governance@aa734d6

It is clear from this change that an explicit list is designed to allow discriminating people based on things which are not in the list (otherwise why make the change at all?). In turn, whatever is protected vs. what is not is chosen based on the militant tendencies du jour. Practically, what this says is: we may discriminate you based on political opinions because we are a bunch of bigots as well.

[mrocklin]

Yes, I agree that explicit lists can be seen as exhaustive, which can be problematic. I think that general statements of "be good humans" are useful, and not mutually exclusive with enumerated lists. Would additional statements like "this list is not meant to be exhaustive, but merely to enumerate some common kinds of behaviors" address this problem?
This is similar in some sense to the US Constitution's ninth amendment

The enumeration in the Constitution, of certain rights, shall not be construed to deny or disparage others retained by the people.

Also

Practically, what this says is: we may discriminate you based on political opinions because we are a bunch of bigots as well

I think that this is bound to happen regardless based on the beliefs and cultural norms uniformly held by whatever group manages disputes. This is one reason, I think, to ensure that this group comes from a group of broad backgrounds, beliefs, ages, life experiences, and so on.

I think that the choice to enumerate or not enumerate common topics doesn't particularly help or hurt this issue. I could easily be wrong about this though.

[pitrou]

Would additional statements like "this list is not meant to be exhaustive, but merely to enumerate some common kinds of behaviors" address this problem?

It would definitely make things better IMHO.

[mrocklin]

It would definitely make things better IMHO.

But would it make things good enough?

I agree with the concern that you raised generally. Personally I'm comfortable if we add language something like what's above, but I only have one perspective here. Are there other ways that we could improve things? Would listing specific common issues be ok with such a disclaimer?

[ogrisel]

I find the phrasing of https://www.contributor-covenant.org/version/1/4/code-of-conduct good enough in that respect.

The lists in the "Our standards" sections are explicitly not meant to be exhaustive: they are "Examples of behavior" that are either encouraged or considered inappropriate. The list in the Pledge section is wide enough in my opinion.

[pitrou]

@ogrisel Well, the list in "Our Pledge" is apparently exhaustive. I agree the "Our Standards" part is ok.

There is also this thing:

Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project’s leadership.

Apparently it's not enough to follow and enforce the CoC, you must do so in "good faith". What does it mean? How is good faith or bad faith to be proven? It seems some kind of religious adherence is expected.

I don't want to overdo this. In practice I'm sure most people don't care about the words a CoC uses, they just contribute as they see fit (hopefully without insulting anyone). Still, if we're discussing which CoC we want to choose, paying attention to words is probably desired.

[mrocklin]

Apparently it's not enough to follow and enforce the CoC, you must do so in "good faith". What does it mean? How is good faith or bad faith to be proven? It seems some kind of religious adherence is expected.

"Good faith" is a common phrase that is not intended to be related to religion. Google defines it as "honesty or sincerity of intention". Sometimes people use the latin equivalent "bona fides" instead.

I think that this sentence means to say that it is not only enough to follow/enforce this CoC technically, as a laywer might follow/enforce it. Additionally we should follow the spirit of the agreement broadly. I use spirit above as is it used in the phrase "to follow the spirit, rather than the letter of the law", which has the same meaning. (sorry to explain English idioms with yet more English idoms).

Given the multi-lingual readership perhaps we should find a better way around the word faith here.

[pitrou]

That's what I assumed as well. But, if someone is attacked on that basis, how are they supposed to prove their sincerity of intention?

A sentence about following the spirit, rather than the letter, would state it in a positive way, even though it's still rather vague.

[mrocklin]

Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project’s leadership

I think that the intent of this text is to say two things:

• "Maintainers are also subject to the CoC"
• "Maintainers are required to enforce the code of conduct well. If they don't do so, then the system should stop them from being project maintainers"''

Do you agree with these two points generally?

I agree with you also, that we should keep the tone positive, rather than talk about repercussions, which seems blame-y and negative. I think that the far more likely break of these rules is that a maintainer is busy and so neglects enforcement. I wouldn't want "repercussions" or any intentional harm done to the maintainer in this case. I would just want the maintainer to be removed and another more active maintainer put in that place. My guess is that in this situation this would likely be welcome on all sides.

[pitrou]

I agree with the first point. The second point looks more contentious to me. Not everyone is apt in delicate mediation roles, and I'm not sure it's a good idea to chastise an otherwise competent and diligent maintainer for lack of skill in enforcing a CoC.

From a broader point of view, if a project has several maintainers, not all maintainers need to be involved in CoC enforcement (the same way that not all of them need to be involved in release management, etc.).

[mrocklin]

Yeah, I can see two different views on this (both of which seem reasonable to me). I'll try to present arguments for each one. I don't see an immediately clear answer here. I encourage other people who haven't spoken up to speak up.

• All Maintainers should be responsible to enforce CoC violations: I think that this essentially boils down to the fact that having a "powerful" person not enforce violations is implicitly seen as condoning the activity. The typical example would be in a company if employees say crude jokes around their boss and the boss doesn't react negatively, then they feel like it's ok to say crude jokes more generally. Lack of action by "powerful" people ends up looking like support, which has negative consequencies.

• I didn't sign up for this responsibility: In OSS we tend to give people authority/rights for volunteering their time/expertise/effort and being generally helpful in a variety of ways. This includes people who want to engage mostly on a technical basis, and have no interest in managing people or personal-conflicts. It seems incorrect that extensive volunteering or work suddenly makes you responsible for the behavior of those around you. This goes from seeming incorrect to being scary if there are negative consequencies for inaction, especially if you don't have confidence that you'll be able to identify what other people think is inappropriate behavior.

[guillaumeeb]

For the CoC part, I'm happy to have a list of examples, be it as exhaustive as possible, but the

additional statements like "this list is not meant to be exhaustive, but merely to enumerate some common kinds of behaviors"

is mandatory too.

For the maintainer role on enforcing CoC, I'm leaning toward the didn't sign up for this responsibility side. But in this case, everyone, maintainer or not, can refer to the CoC to condemn/signal/highlight a bad behavior. Let maintainers who are confortable with this kind of mediations do the job then.

[jrbourbeau]

I'm also in favor of enumerating common unacceptable behaviors with an explicit statement that the list is not meant to be exhaustive. As @mrocklin pointed out this has the added benefit that we

can very clearly point to a line in the CoC and have a very short discussion, rather than have to go back and forth about what should or should not be considered offensive within this community

Regarding enforcement of the CoC, a third viewpoint would be to have a Code of Conduct Committee (similar to how Jupyter handles CoC enforecement) that is responsible for enforcing the CoC. Anyone can report if they think there are violations of the CoC, and the CoC committee is responsible for enforcement. This could serve as a middle ground between the "All Maintainers should be responsible to enforce CoC violations" and "I didn't sign up for this responsibility" viewpoints.

Not sure how much enthusiasm there is for forming a CoC committee, but I thought I would at least propose it as an option.

[mrocklin]

OK, it seems as if conversation has died down a little. I propose that someone (any volunteers) draft a PR to this repository that includes the Contributor Covenant verbatim as a first commit, and then adds in a few modifications based on the conversation here in other commits. That way we should have a good history of what we've changed and we can hopefully have a more targetted conversation on phrasing using GitHub's PR review machinery.

Is this ok with everyone? Is anyone interested in drafting the original PR (we should all be able to modify it afterwards anyway).

[jakirkham]

Not sure how much enthusiasm there is for forming a CoC committee, but I thought I would at least propose it as an option.

Would just like to give my +1 to this. I think this finds a nice balance to the points made in @mrocklin's earlier comment.

If we do go this way, I'd suggest we think a little bit about how the CoC is formed and how we handle changes in its composition (e.g. a member steps down and/or someone volunteers).