Code of Conduct

Development
1

Hi Foreman, I just wanted to make a friendly suggestion. A couple months ago, the Pulp team adopted an official Code of Conduct. Personally, I am glad to see that we have one as I believe it will help to foster a positive and inclusive environment for our developers and community members. I know that Foreman has some informal community guidelines on its site (see Foreman :: Support) but nothing like a formal Code of Conduct.

To share some info, the Contributor Covenant that would make an excellent starting point:

https://www.contributor-covenant.org/

Also, Github has some information about including a Code of Conduct in your repositories and it also has a tool that can be used to generate a Code of Conduct:

https://help.github.com/articles/adding-a-code-of-conduct-to-your-project/

If you all have any questions or need any help, feel free to ask. Thanks.

3 Likes
2

Clear :-1: from me, see https://github.com/theforeman/foreman/pull/4606

1 Like
3

Absolutely agree.

A CoC is as standard today as using a version control system. I’d say that large projects without a CoC probably deserve a little side eye and should be treated with suspicion.

The Django CoC is stellar.

4

While I get the (obvious) purpose of a version control system, I am wondering what the purpose of a Code of Conduct is supposed to be.

Do you mind elaborating this? I do like the Foreman community a lot and trust my fellow community members. I think there is no need for any suspicion.

1 Like
5

This was already discussed and rejected https://github.com/theforeman/foreman/pull/4606

I’m not saying it can’t be revisitted, but what has changed since then?

2 Likes
6

As @dLobatog mentioned in the PR[1], there are Community Guidelines[2] to which everyone should adhere to.

A good compromise could be to add a “Code of Conduct” section to the README pointing towards that?

[1] https://github.com/theforeman/foreman/pull/4606
[2] https://www.theforeman.org/support.html#CommunityGuidelines

1 Like
7

Just wanted to clarify my comment in the PR. What I wanted to say is simply a presence of a document in a git repository means nothing. It’s all about us, our community and our behavior and I strongly believe Foreman community is one of the best. We already have a fraction of what can be called CoC in the Support section of our site, that’s probably the best place for further expansion.

[lzap] I never read these documents anyway :slight_smile:

In the FOSS world it is common to download a tarball or checkout a git repo but never read README, LICENSE or other files. Instead, you go to project site and study documentation and other info there. These files are often distributed with the software and getting installed, people rarely read them. Ability to send a link to a document instead writing arbitrary text is nice in general, but we had just few such an issues for the whole history of the project.

With all that said, I am neutral on this change. I don’t mind having similar document directly in the git repo, but I think we are lucky that we don’t need those for now. I do have some issues with author(s), story and background of this particular document questioning meritocracy to its limits, I’d strongly prefer writing our own one as we go meaning if we have an issue, let’s add new rule.

8

It was rejected by a handful of contributors, and I don’t think reflects the consensus of the larger community.

1 Like
9

:+1: to having a CoC. I’m disappointed by the push back on having one. What do we lose by enshrining what the community already is as an official policy document? The Contributor Covenant is short and to the point, and I’m not sure what content people find objectionable.

2 Likes
10

It’s rather a political manifesto, something I really would not want to have as a base for working together in an open source project.

If anybody would really want to establish a formal CoC, I’d rather suggest the Ruby one (backstory) or the Code of Merit.

5 Likes
11

Whatever the motivation and whether or not you agree with them isn’t the point.

I would rather this be subjected to an up/down vote open to the community at large rather than bickering on discourse about this.

12

How would you define then, who’s community and who’s not?

13

Open discourse polling has been the accepted decision making process for a number of things recently, seems more fair than whoever shouts the loudest wins.

14

So, every discourse account has one voice, no matter, what the relation to this project is?

15

Thanks @daviddavis - while it has indeed been discussed before, it’s still a good idea to revisit things like this from time to time. Communities change, policies change, feelings change.

A year ago, I would have downvoted that discussion. The Contributor Covenant was not as well worded then as it is now, and had things that concerned me. Now, I think it’s in good shape, and I’d personally be happy to accept it, should it come to some kind of vote. I’d prefer we reach a consensus though :slight_smile:

However, I would disagree with this:

To counter this, I’ll point out that @Lachlan_Musicman links to the Djano CoC, and having read it, I’d say it’s not that different to our existing Community Guidelines. Sure, it’s a touch longer, but we explicitly call out many of the same things about behaviour in various parts of our ecosystem. To date, we’ve never had a complaint made against those guidelines, and I’m immensely thankful that we have such a great community.

To those who say “but we’re nice anyway”, I’d also point out that we write tests even though we think we’re good coders, we perform security audits even though we don’t think we’re under attack - surely we could have no objection to clarifying the project’s intentions if we already abide by those intentions anyway?

On the basis that our existing Community Guidelines provide much of the function of a CoC, and expect/promote behaviours covered by a CoC, I’d suggest that we focus on improving the wording of that doc, and perhaps rename it & position it more clearly (and obviously link to it from repos, etc).

To close, I think this quote from the ever-excellent Sarah Jamie Lewis is pretty spot on:

Becoming the very thing you don’t wish to become over a document whose content you already follow, would not be a sensible thing to do. We’re better than that.

5 Likes
16

This doesn’t sound very positive and appealing to me, sorry…

1 Like
17

Sorry, I guess I wasn’t clear in my use of that quote - it’s not meant to be positive. It’s a cautionary tale, taken in the light of the communities I’ve seen tear themselves apart over the suggestion of a Code of Conduct. I believe that’s Sarah’s point, and yes, it’s not positive if we allow it to happen to us too.

The point I was trying to make is that becoming strongly divided over something that is intended to help us work together is not a good result, and that I believe this community is sufficiently strong in it’s own identity to cope with revising a document we already have.

18

Rather than up/down we should allow to pick from options of multiple CoC templates together with option “no we don’t need that”. The CoC text presented in the proposal is not the only CoC in the world and I have to admit there’s some antipathy on my side against the one that is proposed. Overall I like shorter form, without mentoring people how to enforce it.

We also need to vote about the form, because it does not need to be part of the github repository. This is not a license, I believe this belongs to our site.

19

Sure, my point was to have a mechanism for making a decision - like a poll, because a discourse discussion thread isn’t going to get us anywhere. Polling has it’s limitations, but it’s been acceptable without controversy for things like enabling 2FA. Unfortunately we do not have a formal mechanism for making decisions, and it’s largely worked ok, but it’s maybe something that should be revisited if people are worried polling the community isn’t somehow fair.

20

Couldn’t disagree more. The CoC is only as useful as it’s enforcement. The enforcement is the hardest - and most necessary - part.