update CoC to 0.4

[phinze]

see https://github.com/Bantik/contributor_covenant

[nanoxd]

👍

[vitorgalvao]

There’s an extraneous space between the sentences. “Code of Conduct. Project maintainers”. Other than that, looks good.

[fanquake]

👍

[tapeinosyne]

I would like to offer some observations.

Some of the reverted changes from #3112 leave gaps that might be problematic. My main gripe is with the diversity statement: several categories have been removed, and the phrasing is overall less inclusive.

I have other reservations, but I understand that we might want to conform to a standard, common template; perhaps I should move the discussion upstream to Bantik/contributor_covenant?

[vitorgalvao]

Even if only psychologically, I think there may be a point where too many categories might actually seem less inclusive. In a case like this, where it is clear that the goal is to be inclusive of every difference and particularity, if you have a few you’ll likely finish off in your mind with “and so forth”; you can assume they stopped where they did so they wouldn’t elongate the sentence ad infinitum. After a certain threshold, however, it starts to seem like trying too hard to include every group and subgroup, and that might start to look like exclusions are deliberate.

I have no quarrel with including as many traits people might identify with as we can think of, however. I’d just prefer there wouldn’t be a need to, that we could just say We promise to extend courtesy and respect to everyone involved in this project regardless of who they might be. That could also be subject to nitpicking, though.

What the last paragraph of the code of conduct states is basically “we won’t be pricks”; we’re just defining what “not being a prick” means. Does that need to be defined? Unfortunately, yes — to take misogyny in programming circles as an example, I believe some (perhaps most) of the offenders really do not understand they’re being assholes (not that I can necessarily understand how they cannot see that, but that’s a different matter).

On a lighter note, I (not really) propose a summary.

When you submit a PR
Makes no difference who you are
When you submit a PR
We will thank you

In the end, I do think the conversation should be taken upstream, as we could get opinions from users/creators of different projects. I might’ve rambled a bit, but I genuinely understand and agree with your concern. I’m interested in reading what are the other reservations you mention.

[goxberry]

Looks good to me.

[vitorgalvao]

We should decide what to do with this PR. @ndr-qef, it seems like you never did take your concerns upstream. Are you still interested in doing that? In addition to the other concerns you mention, it’s a conversation I’d like to be a part of; I see it as very worthwhile.

[tapeinosyne]

Yes, quite sorry. I will proceed in the next few days.

[rolandwalker]

Like @ndr-qef, I much prefer the wording of old statement. But there are practical advantages to tracking a standard. And unanimous agreement about taking the discussion upstream.

So, merging this seems like the right call. That doesn't mean we have to freeze our CoC forever. For example, anyone is free to submit a PR switching us to Python's CoC.

[vitorgalvao]

@ndr-qef’s proposal has been submitted 17 days ago, without an answer from the project’s creator. That isn’t a long time, until you realise any suggestion apart from small changes (typos and project links) has been essentially ignored (received no answer) for months. In addition, we can’t really say that it is a highly popular code of conduct or anything, judging from the number of stars and linked projects.

All this to say I don’t really see an advantage to us sticking to that particular CoC: it’s not a big standard and doesn’t seem to be very active, which I’d argue is harmful for something of this nature (at least until it is fairly solid, which it currently is not). I agree with @rolandwalker that it’d be good to adhere to a standard — I just don’t think this is the right one. I’m all for reinstating @ndr-qef’s previous wordings, and sticking to our own CoC. @ndr-qef has shown not only great concern with having an inclusive, effective, and objectively good CoC, he clearly is aware of the implications of how it’s constructed. I throw my support behind his suggested changes, over what we currently have.

[rolandwalker]

@vitorgalvao reverting this PR is OK by me. If upstream is not active/responsive, then we lose some of the advantage of following a standard. There is also the Python standard CoC as mentioned above.

While treating people well is exceedingly important, working on the CoC shouldn't require so much time investment across the team. @ndr-qef has taken an interest and done the work. Harnessing that effort is practical.

[vitorgalvao]

Very much agreed. Let’s wrap this up, then. @ndr-qef — would you rather revert this change, or submit a new version (either yours, or one that you feel is good, like the python one)? Trusting your judgement on this.

[tapeinosyne]

Before proceeding, I would like to solicit comments from @phinze, @nanoxd, and @fanquake, who all expressed their support for this PR; furthermore, part of the upstream changes which would be reverted or overridden have been suggested by phinze himself.

I am quite sorry to prolong this discussion, as I agree that organizational proceedings ought to be resolved swiftly, but it would be goofy of me to ignore the opinion of three core maintainers.

[phinze]

I've been lurking on this thread and I approve of the direction that @ndr-qef is leading us. We've got a great team of maintainers here and I trust the group to make sure that our small community of developers is inclusive and supportive of everybody. 💟 👍 🌈