I’m finding this intent/context/question format much harder to read. I think it’s good to include whichever of those components are relevant to what you’re posting but I would have a much easier time reading it if instead of making it into “form fields” people would write it as regular, flowing text. (I do find the heading formatting easier to read than the parenthesized paragraph prefix formatting, at least.)

First, thank you Darja for introducing this topic! I really like the tips for how to make the conversation a productive one.

I also really like the “big tent” conceptualization of Scala that Martin laid out. It very much agrees with how I view Scala and how I use it: I want to be able to go anywhere in that tent because different places have different strengths for solving problems. And, because of the broad applicability, it has a lot to offer people with many different types of problems. By default, since open-source communities consist of people who can use each others’ work, larger is better if all else is equal. (Tradeoffs exist, but the aspiration should be inclusiveness even from a purely selfish point of view; many of us are not selfish in that way and have other reasons to also value inclusiveness.)

Because of the rather expansive nature of the topic, I would like to enunciate some principles that guide my (and, I suggest, should help guide your) thoughts on the matter.

Principles of a Big Tent Goal-Directed Community

Note: by goal-directed I don’t mean that there is a particular endpoint that everyone is seeking, but merely that we’re trying to accomplish something, not just hang out with each other; and that this something has objectively clear succcesses and failure modes. This means that we can’t just decide whatever we like because we have a constraint: we’re doing stuff that should work, and we only partly get to decide what “work” means.

In order of importance:

Intellectual honesty. Software needs to work. Intellectual honesty is a prerequisite for figuring out how to make things work; it also prevents wasting time strategizing, guarding against duplicity, etc… Note that this includes being forthright about what is objective and what is a matter of convention/opinion.

Kindness and generosity towards people. There’s not much point having a community if the members can’t benefit in some way; there are many ways to achieve benefit, but to be inclusive, having a zero-cost emotional overhead is important. Since we are largely the ones who benefit each other, generosity in interactions is not a dispensable nicety but the backbone of the effort.

Respect for or understanding of differences of all sorts. Not all ideas or goals are worthy of respect, but before withdrawing respect one should have a deep understanding of the relevant tradeoffs and constraints that may motivate them. Acting disrespectful to people is not kind, so 2. covers that.

Clarity, transparency, and neutrality in leadership and administration. Favoritism and opinionated endorsements can work fine in exclusive communities but not in inclusive ones. To avoid both the appearance and manifestation of such things, all official actions should be in the open, for clear, well-justified reasons that are based overwhelmingly on technical merit or content.

Appearances matter. Anyone or anything that is widely used or relied upon gains, unavoidably, status as a community leader–they appear to be a leader so they are. Likewise, frequent communication indicates openness and inclusiveness, and so on. Expressions of hostile intent, even if not acted upon, cause emotional overhead. In brief: looking good or bad is not as good/bad as acting good or bad, but it is not irrelevant.

I am happy to discuss either these principles or applications of them to specific cases, but for now I think this is enough.

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.

@runT1ME @SethTisue Core people in Scalaz remain hostile to core values of the Scala community, such as simply being nice. The continued damage done to Scala by them is much greater than any twitter storm, or my decision to stop exposing myself & my team to their toxicity while simply doing our job.

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.

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):

Take all the public name calling, gross exaggerations and insinuations in this thread, and now imagine a private version as a constant stream of little paper cuts.

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: https://mail.haskell.org/pipermail/glasgow-haskell-users/2018-December/026822.html

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.

Intent
I think moderation should be more transparent. The main aim should be education but it should not be punishment. Even ban it is not punishment it is our loseSuggestion
Every bad practice should have clear indicators and descriptions why it is bad or does not work. A moderation action must have a reference to that practice. So that any reasonable person will be able to improve his messages and it shouldn’t matter whether he have too altruistic or egoistic emotions.

Unfortunately John was speaking in a dynamic language called EnglishScript. Its become so popular recently that people are even starting to use it on the back-end. God help us! Anyway I’ve decompiled it

We need to sacrifice half of the community;
Say goodbye to it;
I’m not joking! ;

Notes. This has been left as a Set of IOs. Allowing maximum flexibility. So you could just flatten it and perform unsafeRun on it, or you could break it up into batches. Of course you can’t examine inside the IO, but that doesn’t matter as there is no useful data inside them anyway. I have added type ascriptions that weren’t in the original just for the purpose of education. The key point is the EitherJ bi-functor.

If John had intended this as hyperbole he would have returned it as a Joke, not a Serious[Set[IO[Unit]]]. Its unfortunate that in the untyped and unsafe language EnglishScript this meaning might be obscured to those not familiar with this style of coding. As I understand it John only considers it necessary to have one bi-functor for

serious
1 important, significant, consequential, of consequence, momentous, of moment, key, grave, weighty, far-reaching, major
2.acting or speaking sincerely and in earnest, rather than in a joking or half-hearted manner.

as he thinks we only need one IO monad.

I didn’t link to the video in the earlier post because I was wary of including effectual links. Now maybe you might want to just ignore what I say because if you call John’s “useful” function you will see I’m one of the unwanted Scala Community members. But if not I would suggest that effects really are at the very heart of this debate.

What I’m suggesting is that while querying which community members carry their weight according to the ScalaZ sub-community algorithm may be a pure function, when you do that in a public talk that is uploaded to YouTube you are engaging in IO. And in this case this effectful IO may have had the unexpected side effect of leading to ZIOs exclusion from the community build. Although as John surely knows such a proposition is excruciatingly difficult to test.

Would it be helpful if Scala had a short agreed definition of what the design goal of the language are?

Martin’s blog informally gives a vision for the Scala language, and whilst I believe that a significant number of Scala users support this vision, I’m not sure whether everyone in the Scala community is signed up to that same vision.

To give some further background, I have some experience with another engineering community (IETF) that has to deal with similar conflict resolution between competing solutions and individuals. In the IETF context, they have several mechanisms to help try and manage competing demands. Each of the IETF “working groups” have an agreed charter of what that working group is tasked to do (e.g. IETF NETCONF Working Group Charter). For particular problem domains, sometimes RFCs are written (but perhaps not taken all the way to publication) to reach agreement on what the precise requirements are of the problem that is being solved (e.g. rfc7923 is one example).

Hence the suggestion is that it might be beneficial to have a short specification that defines the design goals of the Scala language, with opportunity for members in the Scala community to review, comment, and contribute on that overall direction.

However, there are a couple of potential risks of doing this: (1) it may cause more short term conflict between different parties, (2) it may slow the process of getting the next version of the Scala language.

I remember a little while ago (a few months?), some one sent a link to
a video of a talk where the conclusion was pretty much that quote. So
I’m assuming that was then Jon De Goes’ talk, though I couldn’t be
completely sure.

The talk started off going over a series of challenges Scala faces,
including a list of competitors, and ended in the conclusion that
Scala is doomed unless Scala sheds its OO features and becomes purely
functional.

I watched the talk and it was not apparent to me that it was
hyperbole. I thought he really means exactly what he said.

It could be that I’m in the minority here, as I’m slightly autistic
and therefore less good in detecting things like hyperbole.

What he said was perfectly in line with some people who used to be
very vocal and never got tired of telling every one that real
idiomatic Scala is essentially functional (“avoid vars”, “mutability
is the new goto”, etc).

I disagree with these people, but they should have the right to voice
their opinions.

I think that’s not off-topic, because that’s exactly what Scala
community is or is not about.

However, I think some of this could be mitigated if Scala’s standard library supplied more of the FP workhorses by default. Currently when contrasted with ScalaZ and Cats (and now ZIO), the Scala standard library “feels” moderately OOP biased, paying lip service to the FP side of Scala. Whether this is “true” or not is a fool’s errand

This perception of the OOP bias in the Scala standard is part of where the “oppositoonal FP ideology” attitudes emerge and manifest in both passive-aggressive undermining of Scala messaging as well as the outright religiously oriented “condemnation and excommunication” behaviors seen by the most billigerant (current and former) Scala FP community members.

Psychology has a rich library of ways to evaluate and mitigate ideologically damaging attitudes and behaviors. Trying to strictly control these psychology conundrums via various communication technology approaches will miss the root cause, and just add participation costs to those who don’t fall into the ideological extremes.

When Martin started creating Scala, Generics had not been delivered to Java or C#. I’m not sure if C# 1.0 even had foreach methods. Some people may snear at foreach, but it was the first thing that got me starting to think functionally, even if I had never heard of Functional Programming. At least as far I’m aware there was nothing with early Scala, that could be remotely interpreted as a promise to provide a platform for pure, inheritance-free, lazy programming on the Jvm.

Over time Martin and his collaborators, have added more and more to Scala to support Functional Programming and ever purer Functional Programming.

We’ve seen the dropping of Any2StringAdd. All of this supports and will support the creation of of strongly typed, pure functional code and laziness. But from a certain section of the functional Scala community, do we see any gratitude towards Martin and the other lead Scala developers for all of this? No we see continual carping, complaining, bile and spitefulness.

If anyone has a right to complain about Scala its not the Haskellators but those that want to stay close to Java, use imperative code or write in a more loosly typed dynamic style. They’re the ones that have lost procedure syntax, and Any2StringAdd. They’re the ones whose Java code may be incompatible with Scala libraries using multiversal equality or other new features.

So it seems the debate is turning towards FP vs. OOP, or FP vs. imperative programming, or similar. I find that a curious divide. John De Goes seemed to me, at least on the surface, not to have anything against specific persons or communities, but found Scala great and feared for its survival and future and sought desperate solutions - though I do not know whether he was sincere or if he had ulterior motives and plans and/or other.

My 2 cents on that topic is that I hope that Java, Kotlin and possibly Haskell will serve me well in the future. The Java and Kotlin language developers, organizations and communities has learned a lot and been greatly inspired by Scala on a considerable number of aspects, including in newer and planned versions, though Scala is still, arguably, much (, much) further “ahead” in some regards (similar abstractions and features to case classes as well as pattern matching have been discussed and investigated by Brian Goetz and others reg. future versions of Java). I would imagine that the same kind of inspiration from Scala goes, albeit likely to a smaller degree, for Haskell, for better or worse for Haskell.

Well said @RichType, seconded. If there is any reason for me (privately) to be careful and take time responding on the continuation of the thread that brought me to this forum; its my appreciation of what Martin and his Scala community have given me. All of what you stated 6 days ago.