haskellfoundation.github.io icon indicating copy to clipboard operation
haskellfoundation.github.io copied to clipboard

Adjust guidelines for respectful communication

Open hasufell opened this issue 9 months ago • 18 comments

Resolves https://github.com/haskellfoundation/haskellfoundation.github.io/issues/463

hasufell avatar Feb 25 '25 14:02 hasufell

I have no idea if there is a process regarding how to update these guidelines. From what I would expect is that the board needs to approve of it?

hasufell avatar Feb 25 '25 14:02 hasufell

I'll have to sit on it a tiny bit more, but I wonder if it's possible to add another sentence after what you've changed, saying that behavior that runs counter to that is not acceptable.

But it seems difficult to word such a thing. I'll think on it.

Edit: I should add that I like your change! I just feel that we should also make clear that certain behaviors are not okay.

jmct avatar Feb 25 '25 14:02 jmct

Explicit intolerance towards toxic behaviors is an important mechanism of a healthy community. I just wonder what the point of that strong wording is, when:

  • in the small internal circle of the HF, it can easily be enforced (and probably does not need to be explicit anyway)
  • in the larger community, it cannot be enforced

I think the only time where it really makes sense to have such strong wording is in places like IRC channels, where there's lots of people and rules need and can be enforced.

hasufell avatar Feb 25 '25 15:02 hasufell

I would prefer to retain a closing statement of what the Foundation does not tolerate and, again, I do not see a need for 'listing', so (or something to that effect):

We do not tolerate behaviour that conflicts with our desire to be welcoming and respectful

I do not object to that -- perhaps immediately after the bullets.

So to summarise, I think we are converging around:

  • Delete the current last bullet "We do not tolerate..."
  • Add a new first bullet "We welcome into the Haskell community people of all backgrounds, identities, and beliefs, provided only that they in turn behave in the respectful way articulated in these guidelines". (I have made a tiny rewording.)
  • Following the bullets, add (as an ordinary paragraph) "We do not tolerate behaviour that conflicts with our desire to be welcoming and respectful". (I'm agnostic about adding this, but don't object.)

Let's see if others agree.

Mike suggests adding

  • We avoid forms of expression and other behaviours that might make somebody feel attacked, humiliated, demeaned, or marginalised - even where we disagree with that person.

But that's already there in (current) bullet 4, isn't it?

simonpj avatar Mar 04 '25 09:03 simonpj

To clarify, my final suggestion on what the Foundation 'avoids' is not an addition but an amendment. The existing guidance has:

  • Where we disagree with someone, we avoid forms of expression that might make our dialogue partner feel attacked, humiliated, demeaned, or marginalised. ...

which (if we lose a positive statement about what the Foundation will not tolerate) I would amend to:

  • We avoid forms of expression and other behaviours that might make somebody feel attacked, humiliated, demeaned, or marginalised - even where we disagree with that person. ...

That is because [1] the existing statement of what the Foundation will not tolerate (which is proposed to be deleted):

  • We do not tolerate any form of discriminatory language or behaviour ...

covers all forms of behaviour (as well as, expressly, the use of language); and [2] the existing clause "Where we disagree with someone, ..." might be taken to limit the circumstances in which the Foundation avoids causing a person to feel attacked, humiliated, demeaned, or marginalised. Moving the 'where we disagree' text to the end makes clear that it is an example of a relevant context, not a qualifier limiting relevant contexts.

mpilgrem avatar Mar 04 '25 09:03 mpilgrem

Oh ok. So the summary is:

  • Delete the current last bullet "We do not tolerate..."
  • Add a new first bullet "We welcome into the Haskell community people of all backgrounds, identities, and beliefs, provided only that they in turn behave in the respectful way articulated in these guidelines". (I have made a tiny rewording.)
  • Reword (current) bullet 4 thus "We avoid forms of expression and other behaviours that might make somebody feel attacked, humiliated, demeaned, or marginalised - even where we disagree with that person."

That's fine with me

simonpj avatar Mar 04 '25 09:03 simonpj

I think "might make somebody feel attacked" is very vague. Many people feel attacked by a mere fact of disagreement; I'm not in control of their feelings, but I'm in control of my intentions. Thus I'd prefer a more actionable and active statement like "We avoid forms of expression and other behaviours that attack, humiliate, demean, or marginalise - even where we disagree with that person".

Bodigrim avatar Mar 04 '25 21:03 Bodigrim

While we have momentum here and without trying to blow up the scope (feel free to discard), it was noted in a CLC discussion that the following wording is problematic:

In our communication, we consistently honour and affirm the passion, professional expertise, and good intentions of others. Even if we occasionally doubt these qualities in someone else, we will not make public accusations of incompetence, malice or ulterior motives.

I think we need to be more careful here. What I think we need to change/outline here is:

  • we assume good faith unless we have good reason not to (and those reasons must be concrete and not of discriminatory nature)
  • we avoid public accusations and any other form of public shaming ("avoid" means there may be good reasons to do so anyhow, e.g. if someones behavior is a threat to the ecosystem)

I think that would make more people comfortable to explicitly subscribe to the CoC.

hasufell avatar Mar 05 '25 05:03 hasufell

I'd prefer a more actionable and active statement like "We avoid forms of expression and other behaviours that attack, humiliate, demean, or marginalise - even where we disagree with that person".

That is fine with me.

I think we need to be more careful here. What I think we need to change/outline here is:

The guidelines are, well, guidelines. The cover the common case. I worry that if we spend too many words covering extreme cases we'll end up with convoluted language that dilutes our intent with delicately phrased exceptions. I wonder if we might want to say explicitly that the guidelines (written in simple language without exceptions) are just that: guidelines? Something like "These guidelines address normal, sometimes-fallible human interactions within our community. In extreme cases, however, members of the community should use their best judgement, following the spirit of the guidelines. They are guidelines, not laws." Would that help?

simonpj avatar Mar 05 '25 08:03 simonpj

Well, I think the wording is pretty strong, it says:

[...] we will not make public accusations of incompetence, malice or ulterior motives

I think there are times when this is necessary.

In my opinion, the guidelines should reflect that a healthy tech community absolutely does speak up about cases of incompetence, malice and ulterior motives.

We just need to make sure to follow due process, in order of:

  • contacting the person in private
  • contacting stake holders in private about that matter
  • speaking publicly about it if all else fails

These situations have happened before in Haskell. And I think it would be good form to reflect that we can deal with bad actors. We just need to agree that public shaming is never our default mode.

I propose:

In our communication, we consistently honour and affirm the passion, professional expertise, and good intentions of others. When we doubt these qualities in someone else, we prefer to deal with those matters discreetly, instead of making public accusations.

hasufell avatar Mar 05 '25 09:03 hasufell

Thanks Julian for pushing on this!

In the most recent version you remove the directive to reach out the the HF if an issue comes up.

On the one hand, I agree that the HF is not the 'communication police' of the Haskell community, and that folks should try to resolve these issues within the body/context in which they arise. At the same time, I feel that there is a role for the HF in these things. The same way that one might approach a trusted 3rd party and say "can you speak to X about Y?".

What do you think?

EDIT: to be clear, this is not a request for a further change. I'm genuinely asking what you think :D

jmct avatar Mar 07 '25 18:03 jmct

I’m doubtful about escalation mechanisms in GfRC in general, but honestly I think that suggesting HF to be involved in each and every dispute by random people on random corner of the internet is an overreach. I hardly see how it can be effective for either side. But it can easily be a huge resource drain, if wielded maliciously.

The text of GfRC referred HF only because it was for HF members. The original edition of GfRC for GHC SC members refers to GHC SC for escalation, etc.

Bodigrim avatar Mar 07 '25 19:03 Bodigrim

I think any mention of the Haskell Foundation makes the GFRC a bad CoC that is hard to sign up to as a third body.

The HF is free to state somewhere else that they are happy to help resolve social issues in important cases. But I'm not even sure that needs to be said or written down. We don't need a process for exceptional circumstances.

E.g. the HF under David helped resolve the situation around the locked down haskell subreddit. I can imagine other scenarios, loosely related to GFRC or other social issues. But we really don't need a process for that.

The HF simply has to gain recognition as a mediator to become a helping hand. Anything else sounds a bit authoritative and doesn't vibe well in the anarchist landscape that open source is.

hasufell avatar Mar 08 '25 02:03 hasufell

EDIT3: When I commented below, I was unaware of:

  • #481.

@hasufell's purpose can be understood by reference to #481.

-oOo-

The purpose reflected by @hasufell's most recent suggested edits differs from the current purpose of the published document, but I think both can be accommodated by restructuring the published document.

  • After some explanatory introductory material, the published document sets out the standards the representatives of the Foundation set for themselves (acting in that capacity). The Foundation hopes that others will choose to follow suit, but does not seek to impose anything on others. The document also sets out what the Foundation hopes will happen if a representative appears to fall short of those standards.

  • @hausfell is, however, looking for a statement of standards that others can readily 'adopt'/'sign up to', for their own purposes.

The solution, I think, is to restructure the published document to separate (a) what is specific to the Foundation from (b) something that others could easily 'adopt by reference'. The current document has a 'sandwich' structure ('bread, filling, more bread'). I would move all the Foundation-specific material (the 'bread') to the first part of the document and put the 'adoptable' material (the 'filling') under a final heading ('Standards of public behaviour', or similar).

EDIT1: It is not straightforward to convey what I have in mind through the medium of commenting on a pull request on HTML in a GitHub repository. Perhaps we should settle the original pull request within the scope of the original motivating issue and then deal with 'repurposing' of the Foundation's published document separately?

EDIT2: The following link to a Google Docs document may be a more accessible way of understanding what I have in mind regarding restructuring: https://docs.google.com/document/d/16Y3ZDl28o8AMu4CdQ4FZk2Wwfm73b5cnTp5q4dgzDHM/edit?usp=sharing

mpilgrem avatar Mar 08 '25 23:03 mpilgrem

The following link to a Google Docs document may be a more accessible way of understanding what I have in mind regarding restructuring: https://docs.google.com/document/d/16Y3ZDl28o8AMu4CdQ4FZk2Wwfm73b5cnTp5q4dgzDHM/edit?usp=sharing

I have no strong opinion on the restructuring. The meat of the text under "Our Standards of Public Behaviour" does not mention "Haskell Foundation", which makes it sufficiently general.

hasufell avatar Mar 10 '25 07:03 hasufell

Perhaps we should settle the original pull request within the scope of the original motivating issue and then deal with 'repurposing' of the Foundation's published document separately?

I agree. Let's land this one. I'm content with its current state. Does anyone object?

(You might want to make further changes but that could be a new PR.)

simonpj avatar Mar 10 '25 09:03 simonpj

Perhaps we should settle the original pull request within the scope of the original motivating issue and then deal with 'repurposing' of the Foundation's published document separately?

Removed the latter.

hasufell avatar Mar 10 '25 09:03 hasufell

Looks good to me.

I'll let the board know they should take a look. I imagine that the board members who have an opinion have already chimed in, but it's worth telling the wider board that a consensus has been reached here.

jmct avatar Mar 10 '25 16:03 jmct

@jmct has there been any progress?

hasufell avatar May 06 '25 06:05 hasufell