Community and Communication going forward

Community
1

Dear Contributors,

We have all been observing the developments in the latest thread for the last week. At the Scala Center, we have also reached out to many Scala community veterans, leaders, maintainers, as well as to the leaders of non-Scala communities for their advice and input. Even though the previous thread was useful as a feedback pool, we believe at this point it turned out to be a too long and unstructured conversation that is hard to follow and draw conclusions from.

We appreciate your time, opinion and effort. We are aware that many of us spent this week engaging in discussions and we want to make your time worthwhile and learn together.

Guided by Martin Odersky’s point of view explained in the new blog post Community and Communication, the Scala Center, supported by many Scala community leaders, decided to continue the conversation in a new, less consuming and more constructive conversation in order to help us create a better and safer community environment. We want to facilitate an opinion exchange that can result in a tangible change. We would like to seize an opportunity to gain something from this experience and make sure history stops repeating itself in the Scala community.

To achieve this goal and make our work lighter, we ask you to follow these simple rules to help us get actionable feedback:

  • Please share your opinion/suggestion/question in a constructive way;

  • Avoid writing ambiguous posts, posts that are vulnerable to multiple interpretations (yes, no one can avoid this 100% but we encourage you to try)

Tip: state your intent, followed by the context as you see it, followed by a question/conclusion/opinion and if possible give a solution (inspired by Evan Czaplicki’s talk “The Hard Parts of Open Source”)

Example:

(Intent) I would like to learn more about the history of conflict between people leading different projects. (Context) The context that I am aware of is that project development suffers because of disagreements between the leaders. (Question) Did I understand well? (Solution) I would understand if this might be too complex to explain, but If this is the case, I would suggest to look at other cases where similar communities successfully dealt with this. link 1 link 2 link 3

We are committed to turning these fruitful discussions into an action plan.
For the Scala Center,

Darja Jovanovic, Community and Communication Manager

15 Likes
2

(Intent) Clarification on the goals and values of the Scala community and its leadership.

(Context) I have previously worked with safety-critical software in Java, including where lives could easily be lost in various ways due to failures, bugs or poor performance of the software, and in such software, the quality of the software - 100% obviously - is strictly much, much more important than the developers and others working on it. An engineering culture where this kind of priority is enforced seems therefore absolutely necessary in order to avoid risking the lives of users and those the users of the software might affect. It also requires that one prioritizes the software strictly higher than one’s own life and well-being, which is the priority I had when I worked with such software.

(Question) The engineering culture as described in the context seems to not just be fully inconsistent with what I get the impression is the most widespread engineering culture and approach among the leadership of Scala as well as large parts of the community, perhaps also the community of Cats - but directly harmed and attacked by this other engineering culture. This seems to be extremely concerning to me, especially because the pool of developers that are hired to work on safety-critical software often times (at least in my experience) overlap very much with general developers, and the wider engineering cultures for better or worse can tend to greatly affect the engineering cultures of those that work with safety-critical software, especially if there is a lack of even somewhat qualified developers relative to the demand. The question is: Do you consider developer communities in general, including the Scala developer community, as well as the leadership of Scala, to have any responsibility in regards to at least not having engineering cultures that are directly harmful and damaging to the kinds of engineering cultures that safety-critical software requires? If so, do you feel or consider that you are upholding these responsibilities or that you would be in favour of changing various approaches to help uphold such cultures? If not, what are your views on such a topic and presentation as I have given here? Disagreement with the presentation and claims? Other?

3

(Intent) Clarification of perceived incompatibilities.

(Context) Having read the previous comment, I’m left with the impression that the described engineering culture (which I’ll refer to as “safety-critical culture” for disambiguation, please let me know if there’s a proper name for it) desires to protect their ability to be abrasive when they feel it is appropriate. As this is not directly stated, further clarification is desired.

(Question) The values of the safety-critical engineering culture aren’t explicitly laid out, and I fail to see how the goals of safety-critical software are incompatible with cultural norms which require mutual respect and professional behavior. Can you explain why this would be the case?

6 Likes
4

Unrelated note: I think I like the intent/context/question format :+1:

Intent

Clarification of CoC implementation guidelines.

Context

I believe the CoC is a very good standard to have, and that it’s effectiveness rests to a large degree both on the consistency with which it is enforced, and the communities trust in the same. As a result, I believe that transparency is a precondition to CoC effectiveness.

I understand that full transparency may not always be possible, principally to protect the identities and privacy of those who are victims of abuse, however I believe some minimum threshold should be established to ensure the effectiveness of the CoC.

I do not believe that the privacy of abusers should be an overriding concern, once allegations have supporting evidence.

Question

In the case where a CoC violation forms the basis or justification for some action, what documentation can we expect?

What should be the minimum threshold for the documentation that must be presented alongside an action driven by CoC concerns?

5 Likes
5

(Intent) Clarifying issue.

(Context) The question by morgen-peschke

Answer: First off, let me note that “professional behaviour” is not well-defined. One definition of it would be to fire those responsible (whether or not the firing is abrasive and/or other) when the extreme lack of responsibility of those fired caused lives to be lost. Another definition would be courteous behaviour at all times (whether or not responsible action such as firing or prosecuting extreme irresponsibility and the like was taken). A third definition would require both courteous behaviour at all times as well as responsible action be taken when necessary.

There may be limited amounts of energy, time, resources, etc. Courteous behaviour can be beneficial, and if it is beneficial overall it should definitely be pursued, but it can also take more energy, time, etc. If one has to prioritize between what is seen as courteous behaviour as well as responsible action reg. lives lost, how should prioritization happen? And will the engineering culture enable correct or satisfactory prioritization? What if firing someone for extreme irresponsibility ends up being seen as not being courteous? What if raising problems or calling others out for irresponsible or poor performance ends up not being courteous? What if the hiring choice before you is a fully qualified engineer who at times can be slightly abrasive on one hand, and on the other is someone who is not at all qualified but is fully courteous, and an engineer being slightly abrasive is not estimated to be a problem for quality neither short-term and long-term? How should prioritization happen then?

6

Intent

Clarification of terms

Context

Ambiguity of “professional behavior”

Question

Would this work as a rule of thumb for determining if something falls within the bounds of professional behavior: “Would this be behavior I’d expect from a lawyer in a the course of providing their services?”

7

Intent

Clarifying compatibility of safety-critical culture

Context

Not a part of the safety-critical culture, but familiar with cultures similar to what’s been described.

Answer

While I don’t believe that responsible behavior is incompatible with respectful implementation of the same (e.g. it’s possible to fire someone for cause, while handling the firing itself in a respectful manner), and that in most cases being courteous actually takes less energy and gets quicker results than being abrasive, how the safety-critical culture handles internal interactions isn’t terribly relevant, provided their external interactions with the broader community are respectful.

With respect to the hypothetical hiring choice, I’d probably recommend passing on both.

  • The fully-qualified engineer may be good, but they aren’t a god, and will eventually make a mistake. Abrasive personalities tend to correlate with ego, and even in something that’s not safety-critical, I do not want to cultivate a culture where the loudest idea wins over better ideas. An abrasive engineer is an unacceptable risk, which grows the longer they are present as the impact of their inevitable mistake grows as they accumulate responsibility and influence.

  • The amiable but unqualified engineer is more nuanced. Everyone starts this way, so junior engineers are almost by definition unqualified for the work we’d like them to be eventually capable of performing. They are a risk, which is mitigated by code reviews and mentoring, so if something they wrote ends up breaking stuff, they are only partially responsible.

    If the engineer is mature in their career and still unqualified, I’d pass. It’s less work to continue searching for someone that’s actually qualified, than it is to get rid of someone.

4 Likes
8

Intent

Clarification of the community’s goals, values and views reg. my earlier questions.

Context

My previous questions and the answers by morgen-peschke.

Question

Thank you very much morgen-peschke, I get the impression that you have made your goals, values and views very clear. I regret to inform you and I am sorry that I get a very strong impression that you are not sincere. My question is, both to you and others more generally: Are these goals, values and views that you describe here more or less shared by the general Scala community as well as the leadership of Scala?

9

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

3 Likes
10

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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

9 Likes
12

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.

18 Likes
13

thanks, it is a vary good explanation why CoC is not a silver bullet.

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 lose
Suggestion
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.

2 Likes
14

John De Goes:

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

3 Likes
15

Without any evidence this is not constructive

4 Likes
16

Could we get a link? There’s no context here, and without this it isn’t helpful.

I could be wrong, but this also seems off-topic.

3 Likes
17

It’s a quote from a talk he gave a couple of months ago. It’s called hyperbole. See https://corecursive.com/009-throw-away-the-irrelevant-with-john-a-de-goes/ for John’s explanation of his style.

1 Like
18

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.:roll_eyes: God help us! Anyway I’ve decompiled it

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

back to the original source code.

val unwanted: Set[ScalaCommunityMember] =
 allCommunityMembers.filter(_.isUseless)
val myPropostion: EitherJ[Set[IO[Unit]]] =
 Serious(unwanted.map(memb => IO(Message(memb.email, "Dear " +  memb.name + " goodbye!"))))

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.

sealed trait EitherJ[A]

Serious[A](value: A) extends EitherJ[A]

Joke[A](value: A) extends EitherJ[A]

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

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.

2 Likes
19

It’s more than just EnglishScript, the tone of voice can’t really be written down. Also its grammar is whatever the opposite of context free is; context is everything.

I’m not saying that I’m not bothered at all by how he made his point, but I don’t think he did anything wrong.

Also his attitude towards Dotty has become more positive since that talk.

2 Likes
20

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.

Regards,
Rob

3 Likes
21

Odersky has repeatedly stated that combining functional and object oriented programming is a design goal of the language. I don’t think that needs clarification.

The problem is that some people are fundamentally opposed to half of that design goal and cannot refrain from fighting about it, yet still want to take advantage of Scala.

7 Likes