CoC-compatible Community Builds

Just to be clear, because I don’t want anyone taking my reply out of context, I’m not telling anyone to walk away. I’m really not. And while I very very much respect @sciss, I do not in any way agree with what he said about “one time posters”. While this has been a very dramatic thread, I respect everyone’s right to have their say, and I think we all appreciate everyone’s passion, regardless of which side of the issue they’re coming down on.

All I was saying with the paragraph that you quoted is that we all accept the leadership of a community when we join that community. We all invest a certain amount of trust in those leaders. That’s just part of the bargain.

12 Likes

@emilypi might want strong justification, but she’s part of that project, so that makes sense. The broader issue that I’m interested in, and this seems to be a common interest, is how it was done.

Specifically:

  1. The decision was made to remove it.
  2. Ostensibly, this was because it was more trouble than it was worth.
  3. An accusation of CoC incompatibility was made in the PR with no documentation.
  4. Requests for transparency were shut down.
  5. It finally came out that maintainers on the Scalaz side were consistently violating the CoC, which did not need to be hidden, and would certainly qualify as a CoC incompatibility.

1, 2, & 5 are not a problem. 3 & 4 are very much a problem, particularly because the public face of this is @adriaanm, who is a SIP Committee Member.

The TL;DR is:

  • CoC violations should be serious business, and need to be handled with transparency. I’m willing to compromise on this to protect victims of abuse, but never to protect the abusers. “Who did what” and “when they did it” should always be very clear, even when the identity of the victim to needs to be kept confidential.
  • The maintainers have shown clear contempt for the requests for transparency made in this thread, and there’s no indication this will not transfer to weightier matters (like the SIP process).
3 Likes

And that’s fair. I also think it is part of the bargain for the leaders to invest in community concerns, such as the way in which we handle CoC violations.

2 Likes

Thanks, and I’m sorry that I misread your intent. Perhaps because @Sciss’s comment was so fresh when you originally posted, I read more of a “put up or leave” tone than you wanted to communicate.

My point is less that there is no trust, and more that this trust is variable and actions like this can severely erode this trust. The inability to walk back on the way this was done is inarguably worse than the initial problematic behavior.

We’ve heard, “yes, this could have been handled better” from @sjrd and a few others, and I don’t think anyone’s disputing @adriaanm’s prerogative to add and remove projects, but that’s not really the core problem.

What shocks me is that the closest I think anyone has come to “Sorry, throwing out an allegation of misbehavior without any context or way for it to be addressed was not the way we do things here, we won’t do it again” is this lukewarm statement from @sjrd:

3 Likes

In this case there can’t have been a CoC violation, because none of the scalaz projects have a CoC. That makes them violating their CoC impossible.

Yes, it is: community-build/NOTICE at 2.12.x · scala/community-build · GitHub

Copyright 2013-2019 Lightbend, Inc.

@nmcb the Scala Center Advisory Board has not discussed this action. My personal opinion is that it is in the community interest and I support @SethTisue and @adriaanm and others involved in the decision. That’s all I have to say right now.

10 Likes

Uhm, I wasn’t aware that The Scala Programming Language · GitHub was a Lightbend product…

1 Like

Nothing has been done on the Scalaz side, this is solely within the context of the Scala Community’s Code of Conduct, which is relevant because we’re talking about the Community Build.

The actions in question were in relation to their participation in the Community Build, not their internal communications/processes:

@adriaanm unquestionably had the prerogative to remove them on this basis. For what it’s worth, I agree with that decision, based on the information currently available. I don’t agree with the lack of transparency in how it was done, or the responses to requests for clarification in this thread.

2 Likes

I don’t feel that this statement has cleared up the ambiguity one bit. First, I don’t see why any communication back-and-forth related to the community build of an OSS project has occurred via private channels to begin with; this seems like as straightforward a thing as referring to an issue on the Scalaz issue tracker that merits the exclusion from the community build (until it is fixed.)

I’m well aware of the long history here, and can’t help interpret this as an explicitly vengeful act toward a part of the Scala community who have historically had differences of opinion with respect to Lightbend’s priorities for Scala. I think however that @djspiewak is correct in that scalaz is not in any way “owed” inclusion in the community build. But it reopens an old wound, and it makes me sad to see that even though I’ve personally moved on from Scala, the wars of years ago are still being refought. If a programming language community can’t eventually bury the hatchet, what hope is there for humanity as a whole?

9 Likes

Thank you for your reply. It means a lot to me to know the opinion of senior members and leaders of the community in this. A community that, I presume as much as you, I care for, as well as depend upon.

When some maintainer contacts an external project, for example scalaz, because the community build breaks, then that communication can’t be forced to be under the CoC of the community build - you can’t contact someone and then demand they communicate with you on your terms.

1 Like

Participation in the Community Build is voluntary, and by project request.

This implies a willingness to participate within the bounds of the CoC.

1 Like

You are absolutely right. But there is other coin side.
An external project cannot demand its support if it does not fulfil requirements of maintainer.

  • The balance of interests have been establishing at any cost

Although it is a sad price in this case.

How is this comment helpful?

Can you please identify the abusive behavior that you’re referring to? I keep seeing oblique references to it without concrete identification of who or what we’re talking about here.

And with respect to your “unobjectionable common sense” I believe that part of what has made Scala a desirable language for many people is the ability to use it as suits their own tastes. It is not up to the maker of a tool to decide how others choose to use it - and the suggestion that people go use Haskell instead is less a productive suggestion than “go away, your kind isn’t welcome here.” And that’s the opposite of community-building. Indeed, I think that that suggestion itself could easily be construed as abusive.

3 Likes

On the abuse, I don’t know what Adriaan means. I give mine below, but I know examples are pointless.

Examples won’t help because we have no shared norms of behavior (no shared CoC, to go full circle); so, what’s abuse for the Scala CoC is not abuse for those who don’t accept it. I think some behaviors are just not “professional”, but Scalaz doesn’t seem to accept even John de Goes code of professional behavior?

But since you keep asking, I’ll give my personal take: does Tony Morris’s vitriol on Scala and its leaders represent the point of view of the Scalaz project? (People are welcome to check his feed if they want.) I think yes, because I’ve never seen anybody on the Scalaz side see any problem with his behavior. Last I went on Scalaz’s Gitter, people asked me the same question, and they’ve tried gaslighting me by insisting there was no problem with their behavior.


[…] edited away

4 Likes

Tony hasn’t been involved with Scalaz in years, and he’s never been involved with ZIO. So if this is some sort of quest to obtain a disavowal of Tony, it’s both petty and pointless.

4 Likes

You’ve asked for examples, I’ve given the most obvious one.

What actually matters is the professional respect and the shared norms needed to work together. Summarized by the Scala code of conduct.

The Scalaz community has never accepted the rules of the Scala community, and has kept violating them and tolerating offenders. I do not believe that has changed. You imply things changed; if they now accept the Scala code of conduct, or something of their choice that guarantees the needed respect, they could announce that.

2 Likes

Just to make a point; you (any of you) don’t know if I contribute to Scalaz. If I did, you would see exactly what you currently do. There is no way I would contribute anything publicly again in that context. None of you have any idea what I contribute to Scalaz.

@Blaisorblade Just keep your gross ideas out of Scalaz. I expect you don’t know what I mean here, and that’s fine, but also not something I am prepared to explore. If pressured, I will force those gross ideas out, like I have done before, and accept all the penalties of having done so. Scalaz is the first Scala project to ever have a CoC. The fact that, if you were come to know it, and that it doesn’t look like anything that some of you might call a CoC, is not Scalaz’ problem. In my opinion, this is a very very very good thing; no it is not compatible with the gross stuff that is now elsewhere, but very much not inside Scalaz anymore.

Just keep all these under-developed, gross ideas on places like this. They won’t be coming back to Scalaz.

Cheerio, I am enjoying the show.

3 Likes