Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Choose off-the-shelf CoC #1

Closed
snoyberg opened this issue Nov 7, 2018 · 21 comments · Fixed by #6
Closed

Choose off-the-shelf CoC #1

snoyberg opened this issue Nov 7, 2018 · 21 comments · Fixed by #6

Comments

@snoyberg
Copy link
Owner

snoyberg commented Nov 7, 2018

The proposal calls for two documents:

  • A standard, off the shelf CoC
  • A custom document

This issue is for discussing exclusively that first point.

Based on my previous research and discussions for Yesod, I lean towards choosing the Contributor Covenant Code of Conduct. I'm quite open to other ideas here.

@vedksah
Copy link

vedksah commented Nov 7, 2018

I don't think you can go wrong with the covenant code of conduct

@tomjaguarpaw
Copy link

From the CCoC front page:

A code of conduct without enforcement sends a false signal that your project is welcoming and inclusive, and can create a dangerous situation for marginalized people who participate. ... Document the policy and procedure for enforcement ... Consider if your project team has the willingness and maturity to follow through on your enforcement procedures.

Are there specific plans for enforcing the Coc?

@snoyberg
Copy link
Owner Author

snoyberg commented Nov 7, 2018

I absolutely reserve the right to enforce the CoC insofar as it is within my power to do so, and intend to abide by the requirements of the CoC to respond to reports of violations. However, as I tried to get at in the blog post, there are major limitations to what I can do here, given that anyone can self-select into the Stack "community", and there is no enforcement mechanism available to exclude people. Also, as I mentioned in the blog post, I intend to continue my practice of both private comments and—when necessary—public comments, for behavior which is not in the spirit of the CoC.

@DanBurton
Copy link

The readme states that this repo is for the "Unofficial Stack Code of Conduct". Why unofficial? Does it become official at some point?

Document the policy and procedure for enforcement

+1 to doing this. Enforcement could include some sort of 3 strikes policy, leading to blocking an individual on certain GitHub projects, from stack-specific gitter conversations & irc channels, or from the stack mailing list. Individuals need only be blocked on the specific forum(s) where they repeatedly exhibit bad behavior.

What happens on #haskell irc, r/haskell, or haskell-cafe & other general purpose Haskell mailing lists, would be out of scope for enforcement since this is the Stack CoC. It could still provide a nice reference point, though, for reminding people on those forums what (at least part of) the Haskell community considers to be appropriate behavior.

@snoyberg
Copy link
Owner Author

snoyberg commented Nov 7, 2018

What I'm describing here is for an amorphous "Stack community." There's certainly room to have a CoC added to the Stack project itself, I'm not opposed. But I'm not going to decide to unilaterally impose that, it would be a discussion. That's why this is unofficial: it's something I'm saying with the full authority I have over myself, no one else.

@tomjaguarpaw
Copy link

there is no enforcement mechanism available to exclude people

I appreciate keenly that it is is very difficult to see how to enforce a CoC in the Stack community, but the CCCoC does very specifically state

A code of conduct without enforcement sends a false signal that your project is welcoming and inclusive, and can create a dangerous situation for marginalized people who participate

I think it's critical to address this apparent contradiction.

@snoyberg
Copy link
Owner Author

snoyberg commented Nov 8, 2018 via email

@tomjaguarpaw
Copy link

I'm afraid I don't understand and I think I must have got the wrong end of the stick so I'm going to eject from this discussion.

@DanBurton
Copy link

As I understand, the method of enforcement suggested by the blog post is this:

If someone within the Stack community is seen as misbehaving, [there will be] a mechanism to politely and confidentially raise the issue, and hopefully have the situation improved

Said mechanism is presumably "email the address listed under the 'Enforcment' section of the CoC": https://github.com/snoyberg/stack-coc/blob/f66641d962dc798099f3b6425bb89e183081eda2/CODE_OF_CONDUCT.md#enforcement

The exact nature of how such emails will be handled is not specified.

The CoC states

All complaints will be reviewed and investigated and will result in a response that is deemed necessary and appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.

We may want to come up with a document with "further details of specific enforcement policies."

@DanBurton
Copy link

@snoyberg

I've never said nor implied that there is no enforcement mechanism.

Perhaps you can understand that the following statement could be misinterpreted as such:

anyone can self-select into the Stack "community", and there is no enforcement mechanism available to exclude people.

@tomjaguarpaw, I believe when @snoyberg said in this quote that "there is no enforcement mechanism", he meant within the context of Haskell forums not specific to Stack. See my earlier comment for elaboration. I invite you to un-eject from the discussion, if you would instead like to continue to work towards a mutual understanding.

@snoyberg
Copy link
Owner Author

snoyberg commented Nov 8, 2018

I don't actually see how that can be misinterpreted:

there is no enforcement mechanism available to exclude people

There are certainly other enforcement mechanisms, but for a community wide policy, we cannot force people out.

@dbaynard
Copy link

dbaynard commented Nov 8, 2018

Perhaps something to consider is that stack already has a CoC — it's just implicit. The proposal replaces this with an explicit code.

Beyond that, I've found https://opensource.com/business/16/6/bad-practice-foss-projects-management generally interesting — on CoCs it suggests that lacking even an implicit one can cause problems.

@agentultra
Copy link

I support the adoption of the Contributor Covenant; it seems like a good one. Thanks for putting it out there!

With regards to enforcement I think it will have to be the decision of a community leader to make a call. The first step, in my opinion, is to block PRs from those deemed to have violated the CoC until such a time as a remediation can be made.

For someone who has a good reputation who makes a mistake a simple apology is often all that is required.

Permanent blocks are something that should be reserved for more serious violations.

I do believe that most people are good and we won't have any problems. Adopting this CoC will help those of us who are more at risk of harm from poor behavior. I think we need to ensure that whatever code we adopt that enforcement means something for those people.

@charukiewicz
Copy link

charukiewicz commented Nov 9, 2018

The proposed Contributor Covenant (#4) uses a lot of ambiguous language that can be interpreted in radically different ways by different people. Its scope also reaches far beyond the conduct of individual contributors.

Examples of behavior that contributes to creating a positive environment include:

  • Focusing on what is best for the community

Who is to say when someone is or isn't focusing on what is best for the community? When two people disagree on what 'focusing on what is best for the community' entails, is one of them in violation of the CoC?

Examples of unacceptable behavior by participants include:

  • Other conduct which could reasonably be considered inappropriate in a professional setting

Who defines what can be 'reasonably considered inappropriate'? Who defines what a 'professional setting' is?

Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct

This seems like a serious overreach and I think is the reason why there is a lot of resistance to CoCs in the OSS community general. The purpose of this type of document should be to define rules for contributor behavior, not as a replacement for technical decisions. This document should only cover the rules for the discussion of changes to the code, not the actual changes themselves.

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.

Not every project maintainer may be interested in (or feel capable of) enforcing conduct.

With all this in mind, I propose using a document like the PostgreSQL Code of Conduct as a starting point. Granted, the PostgreSQL CoC has some really heavy machinery for managing conduct (it defines an entire CoC Committee for complaint handling), but I think that a slimmed down version that uses the same language for describing appropriate conduct but relegates the complaint investigation & handling to a small group of willing volunteers would be suitable for smaller projects like this one.

@DanBurton
Copy link

In response to @charukiewicz

The purpose of this type of document should be to define rules for contributor behavior, not as a replacement for technical decisions.

Think: an error message worded inappropriately. Nobody's saying that the CoC gives anyone authority to step in and make arbitrary technical decisions. Project maintainers are stated as the ones enforcing the CoC, and they call the shots on technical decision anyways, so I'm not sure I get the concern here.

Not every project maintainer may be interested in (or feel capable of) enforcing conduct.

So then don't adopt a CoC for those projects.

Perhaps it's worth clarifying that if Stackage adopts this CoC, that it is not imposing it on all packages on Stackage. They are not subordinates, they are independent projects which happen to be collaborating with Stackage.

Who's to say... who defines...

@snoyberg is. his email is on the Enforcement section, so requests for CoC enforcement go to him. He has already expressed (see README.md#Scope) his intent to have a very light touch on enforcement, and to discuss "with the rest of the Stack leadership" if and when a serious response ever becomes necessary.

It's unnecessary to lawyer out exactly what "focusing on what is best for the community" or "conduct inappropriate for a professional setting" mean. The community pretty obviously agrees with these general principles. If in doubt, you could always check with @snoyberg first.

I propose using a document like the PostgreSQL Code of Conduct as a starting point

This seems pretty good, but the goal (as stated in the blog post) is to pick an "off the shelf" CoC that requires little to no modification. This CoC is one that Michael has already been using for Yesod.

I do like the how PostgreSQL CoC is very clear about how complaints will be handled; we could benefit from adapting portions of that to a supplemental document. Nonetheless, I continue to prefer the Contributor Covenant CoC.

@charukiewicz
Copy link

@DanBurton project maintainers are tasked with enforcing the standard, but nowhere does it explicitly say that they determine what the standard is. What is or is not a violation of the CoC is apparently up to the interpretation of the person reading it. If you think something is "reasonably considered inappropriate in a professional setting", then you are apparently in the right to send an email to the maintainers. And if you are unhappy with their decision, you can petition for their removal under the guise that they are not acting in "good faith".

If you think there is too much work in adapting the PostgreSQL CoC, which does not open the doors to these problems, then my suggestion is to make the document more explicit and add a line that says:

Project maintainers will determine and define the standard for what is considered a violation of the Code of Conduct. In the event of a dispute of the interpretation of the Code of Conduct, the project maintainers will have the final say.

I am certainly not talking about all of Stackage when I refer to maintainers that do not want to police behavior. I am talking about all current and future maintainers of/within the Stack community (and anywhere else this CoC may get applied). This community/project is a very important piece of the Haskell ecosystem. The goal should be to allow someone who is technically brilliant to maintain the project in the future but defer policing behavior to others if they do not wish to be involved in this. @snoyberg may be happy to do both right now, but will everyone always be? Under the Contributor Covenant, they will apparently have no choice.

The PostgreSQL CoC solves this problem by drawing a distinction between a Core Team of technical contributors and the CoC Committee that reviews misconduct complaints. As mentioned before, such a committee here could instead be a less formal group of volunteers.

The fact that Yesod already has this CoC does not mean that it is the best choice (and I think @snoyberg recognizes this or he would not have started this discussion). Whichever CoC is selected should ostensibly be explicit and make it easy to unambiguously navigate nearly any situation involving personal misconduct (by explicitly defining what behavior is unacceptable, how complaints are to be submitted and handled, and who has the final say). The Contributor Covenant, with its fast and loose wording, fails to do this.

@snoyberg
Copy link
Owner Author

The fact that Yesod already has this CoC does not mean that it is the best choice (and I think @snoyberg recognizes this or he would not have started this discussion).

Yes, that's certainly true. To be clear, right now, we're talking about an unofficial piece of the Stack community, which essentially just means how I will interact with reports of problems. But it's fair to be thinking about the future, assuming this is a test run for adoption in the Stack project or even the commercialhaskell organization.

I'm not commenting much on these threads right now, I'm more interested in reading the comments. I do appreciate everyone's input. The major concerns that have been catching my eye have been the ambiguity of the document and the concerns around enforcement. I tend to agree with the concerns. Let me argue the other side slightly:

  • Enforcement: I'm opposed to any kind of "mandatory sentencing" guidelines. I believe the maintainers (in this case, me) must retain flexibility in choosing the enforcement mechanism. I understand that there could be concern in unbalanced treatment, but the same could be said even with an official enforcement standard. I take the comments from Contributor Covenant to mean that there must be some enforcement available, otherwise the entire process is a sham. I agree with that too.
  • Ambiguous language: yes, the language is ambiguous. One thing to note is that the ambiguous language should really be taken as guidelines to strive for. I wish it was more explicit in CCoC, but I'll say here: honest mistakes do happen, and they should be dealt with. But if there was some reasonable ambiguity about whether some behavior was acceptable, I believe we should try to give the benefit of the doubt.

I hope these comments make sense. Let me raise one other objection to CCoC which I haven't seen here: I may be shoehorning the wrong document into this repo. CCoC seems more more amenable to an official capacity. It may be worth, in this case, writing a custom document, explaining that this is due to the unofficial nature (as described in the Scope section of the README), and punt on the official CoC if it comes up with Stack or commercialhaskell.

@DanBurton
Copy link

I'm opposed to any kind of "mandatory sentencing" guidelines.

On the flipside, it may be worthwhile to specify the limits of enforcement. e.g. "first-time offenders may be blocked for no more than 24 hours." This could help put people's minds at ease, so that they aren't fearing arbitrary enforcement due to exact policies not being specified. I'm not sure this fits in with the "unofficial" vibe that you are going for, though, because any specification of potential enforcement has an air of officiality.

@snoyberg
Copy link
Owner Author

It's a nice idea. As it happens, I was talking out something similar yesterday, and realized that there's some behavior which is so egregious (e.g., calls for genocide) that I would recommend an immediate, permanent block. We could make up special rules like that, but ultimately, something's going to slip through the net. At the end of the day, most of this seems to come down to some level of trust: trust that incorrect behavior will both be recognized and responded to appropriately (neither too harsh nor too lenient).

@charukiewicz
Copy link

charukiewicz commented Nov 11, 2018

Let me raise one other objection to CCoC which I haven't seen here: I may be shoehorning the wrong document into this repo. CCoC seems more more amenable to an official capacity. It may be worth, in this case, writing a custom document, explaining that this is due to the unofficial nature (as described in the Scope section of the README), and punt on the official CoC if it comes up with Stack or commercialhaskell.

I think you have articulated a feeling I had been experiencing about this discussion but could not put into words. A document labeled "Code of Conduct" is going to be perceived as an official set of rules and procedures for dealing with misconduct. Yet the aim of this entire repository/proposal is improving communication rather than policing it. There's a dissonance between selecting a CoC (the focus of this particular discussion) versus creating informal guidelines / standards that encourage better behavior in the community at large (which seems to be the overarching goal of this entire repo / proposal).

I agree with your conclusion and think that it may be worth deferring the selection of an official CoC if it does not serve the intended outcomes of this repo / proposal. A custom document that better addresses the stated goals might be a better move for now.

snoyberg added a commit that referenced this issue Nov 11, 2018
@snoyberg
Copy link
Owner Author

I've taken a first stab at a custom CoC in pull request #6. I'd certainly appreciate any feedback participants here would like to offer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants