Thank you @darja , and the Scala Center team, for being open to a discussion. I see this as progress.
As some background, I have been one of the top contributors to the Scalaz 7.x series (besides Yoshida-san, the maintainer) over the last two years, which was a side effect of writing a book on Functional Programming https://leanpub.com/fpmortals
Context
From our perspective in Scalaz, nobody I have spoken to has had any interaction with the Scala Community Build team except Yoshida-san. Indeed, I have personally had nothing but amicable exchanges with Seth for the last 5 years, barring a dispute last year that we later cleared up. So we are very confused why any action has been taken to remove our projects. Being included in the community build is, however, for the benefit of the Scala Compiler Team, and not us, so we will accept that decision. If it had been proposed as “we don’t have time to maintain this” then nobody would have paid it any mind (much as pcplod was recently removed for this reason).
Hurt
Many of us are very upset by the implication that we are damaging to the community by association.
https://twitter.com/adriaanm/status/1122779796575014912
Personally, I’ve put 18 months of my own time (2 hours every night, one day at weekends, some time off coinciding with paternity leave, two full weeks of unpaid holiday leave) into writing a book as a gift to the community.
The profits were donated to development of scalafix (a Scala Center project) to benefit the Functional Programming community. Sponsorship of Vladimir for Functional Programming features · Issue #451 · scalacenter/scalafix · GitHub
I could list many other things I’ve done for the benefit of the community, including my contributions to other projects, conferences, and guidance to the Advisory Board, but that would be a distraction from the topic at hand.
Many others volunteer their time and passion to the goal of furthering Functional Programming in Scala. So I hope you can understand why so many people have reacted emotionally, and hurt, at the implication that they are “toxic”. As a solution to this particular point, I feel an apology would be in order to clear the air. In particular, I think Adriaan’s words hurt the most people when he branded “Scalaz maintainers” and “core people”. The ambiguty regarding who he was referring to (we still don’t know), has meant that we’ve all had to live with the stigma.
Many of us are not working in Scala jobs and, frankly, Adriaan’s words make it very difficult for us to ever return: and that impacts our careers and families. This is not a risk that should exist for volunteer contributors who are working to make Scala better for everybody.
Code of Conduct
Scalaz does not have a written code of conduct, but it has an ethos. That ethos is “be better”, both as humans and as engineers. CoC or no CoC, Scalaz members do not like to see ad hominems or other “not being better” behaviour of that nature.
Where we differ from the “official” Scala community, is that there are no moderators: we believe it is best that social norms and rebutals are set by peers. There are no bans, except that one time Tony was banned by a rogue admin. So if you see something in a scalaz channel that you think crosses the line of civility, speak up!
If this is not something that you are prepared to accept, then we respect your right not to engage on Scalaz channels, or to link to Scalaz from your projects, or even to read or aid in promoting my book due to its use of Scalaz (as Lightbend, EPFL, Typelevel and Scala Center chose to do). But we then kindly ask that you do not tell us how to run our community, and to refrain from speaking negatively about us through association.
You may feel that the Scalaz approach to community management doesn’t work. And I will admit that it doesn’t always work. But I have plenty of examples of where codes of conduct don’t work either.
There is no point pressing this issue. Scalaz is not going to implement the Scala Code of Conduct for its channels. But everybody can each choose to engage on other channels using whatever code they prefer. I think the diversity of community styles is actually a good thing.
Solutions
As to additional solutions to the general problems, beyond the apology that I have already requested, I have some further ideas:
Recovery Centers
As a maintainer of multiple successful projects, I have received a lot of abusive comments directed at me personally, and I’ve burnt out because of the demands on my time. But that’s not something the Scala moderation team gets involved with, because it never happens in Scala channels, and although we have “police” we have no “recovery centers” or even the knowledge with how to deal with that, increasingly common, situation. It’s something I’d like the community to consider, instead of focusing on crime and punishment.
Sentiment
How should moderators measure “negativity toward Scala”, and how much should they enforce it? I believe measurement can only be achieved by having a representative group of diverse peers who can reach consensus on a case-by-case basis. If the moderators are a tightly knit group of friends with similar demographics then it is only inevitable that a kind of “old boy’s club” will be created with strong biases and cultural misinterpretation of intent. For example, interpreting the linked thread as a “troll” when it fact it was a very upset contributor.
Inappropriate bans and public shaming are hard for a community to forgive, and alienate contributors, so erring on the side of good faith should always be preferred in my opinion. However, I understand that Scala is looking to Rust for inspiration and Rust’s founder (https://twitter.com/graydon_pub/status/1121609262134779905) has taken the opposite approach, assuming bad faith when in doubt. If Scala wishes to do it this way, I think you should make it explicit. There is no solid evidence to say which approach increases inclusion, so it’s all still a big experiment.
Empathy
I believe that overstepping a room’s rules can be handled in a non-confrontational way: contacting people privately to ask how they are doing (i.e. de-escalation with empathy), or by peers responding with “that’s not the kind of thing that makes me want to continue this discussion” (i.e. a withdrawal of interest). This is why I prefer the Scalaz approach.
In contrast, the authoritarian approach (threatening punishment / exclusion) may be cathartic for the moderators, but it generates fear and bitterness. “Wrong thinkers” (who are likely to be passionate about Scala) find themselves excluded and unwelcome, leading to tribalism and an overall negative perception of Scala in industry. I would like you to reflect upon this.
This goes both ways and anybody who disagrees with the moderators must also strive to be empathic. As Adriaan describes his own feelings on the matter (regarding private conversations that none of us are privvy to):
Attempt not to Misrepresent
Something that is very frustrating is when somebody is portrayed as having an opinion that they do not hold. For example, that everybody in Scalaz wants to remove subtyping, because one person who uses Scalaz said it once. This is false and anybody who has followed John’s work in ZIO will see that it makes great use of subtyping (he’s made cakes bake again!). If Scala is going to moderate its channels, then perhaps misrepresentation of ideas should be something that is included in the list. It is far better for everybody to understand what everybody means rather than attack straw men.
Lead by Example
According to the Scala Code of Conduct, moderators are expected to uphold the standards higher than others and can expect less leeway if they break the rules. I think it would be fitting if this was extended to anybody who is involved with an offical entity, such as Lightbend, EPFL (including students outside of Martin’s team, the perception is important), Scala Center and the SIP. I think this is quite in line with corporate codes of conduct and is also the approach being taken in the Haskell community, where community leaders (e.g. for the advisory boards) have more responsibility to be a shining example to the community: Guidelines for respectful communication
We are not trying to impose these guidelines on members of the Haskell community generally. Rather, we are adopting them for ourselves, as a signal that we seek high standards of discourse in the Haskell community, and are willing to publicly hold ourselves to that standard, in the hope that others may choose to follow suit.