CoC-compatible Community Builds

#1

I’m hesitant to bring this up, but it is cause for concern.

Community builds are gathered in a repository located here. This list is part of an ongoing effort by Scala to catalogue and categorize community projects. However, one of the more recent commits removes Scalaz and Scalaz-associated projects Zio, Testz, and Argonaut (as well as argonaut-shapeless, presumably due to scalaz compat) under a cryptic commit message: remove Scala-CoC-incompatible projects

No where, at any point in the entire project does it detail that “CoC-compatibility” is a requirement for entry into this repository. Additionally, a snapshot of the Elegibility.md from the wiki also fails to mention this.

There doesn’t seem to be any rhyme or reason to this exclusion, and similar projects which fail to have even the slightest documentation concerning a CoC (like specs2, wartremover) were left alone. Could someone detail the reasoning? Seth?

41 Likes
#2

In the past, we were forced to include these now-removed projects because too much of the eco-system depended on them. Now that’s no longer the case, we don’t feel they pull their weight anymore.

Maintaining the community build is a large investment, and inclusion in this list needs to be earned, both on technical and social merit. On both counts these projects fall short of our bar: they have become a small island in the dependency graph, and the negative sentiment generated by a few very loud scalaz maintainers is damaging to the community.

Of course we will continue fixing bugs in the compiler if these projects discover and report any regressions, but we feel the coverage of the community build is sufficient as it stands, and it would be unlikely that we won’t have already caught the issue thanks to the remaining projects.

19 Likes
Community and Communication going forward
#3

Code cannot break CoC.

20 Likes
#4

My advice is to select one of the following options:

  • remove community from the build name
  • ask community what they think about the change. This can be done either with a proper vote or just with likes in this thread.

I have very little interest in scalaz itself but such political moves makes me look toward other languages more.

38 Likes
#5

inclusion in this list needs to be earned, both on technical and social merit
… the negative sentiment generated by a few very loud scalaz maintainers is
damaging to the community.

When I (and I suspect many others) choose which languages and libraries to use: I look for technical excellence and applicability to solving complex problems. It is for that reason that I have respect for the technical abilities of repo/build owners to make decisions based on these technical merits. At no point have I signed on to accepting their political/social opinions. One who has technical skill is not magically endowed with political/social sense.

Even though I don’t use scalaz either, I am less concerned with repo maintainers that are “very loud” than I am with those whom like to assume the role of morality police.

As someone who grew up in a country where this sort of thinking was common-place: I know where this leads, and it is not good.

I too am considering moving to other languages, for this reason.

19 Likes
#6

I think this is the question i have, did scalaz maintainers treat someone on your team awfully? Especially when trying to work with them to resolve builds? Then i think removing the project is completely understandable, and better to quote and share exactly what happened: “After repeated hostility by project maintainers we’ve decided to remove scalaz from the build citing incidents here, here and here.”

No one has time to work with assholes and that is completely understandable IMO. But if you don’t like what they’re writing on their personal blog posts or conference talks then we all better take a deep long hard look in the mirror. :wink::joy:

12 Likes
#8

This is such a ludicrous statement that it can’t possibly be genuine and seems retrospectively contrived to justify a stupidly petty action.

You say they have become a small part of the dep graph. How has ZIO ‘become’ anything it’s less than a year old.

Luckily the real motivations is in the commit message. Please explain how ZIO, the brand new project with zero dependencies, is incompatible with the scala coc?

7 Likes
#9

You do realize that if your post gets “censored” it won’t be because of your opinion but because of the way you expressed it?

Nobody is being censored here. The community build maintainers are simply choosing to invest their time in other projects.

4 Likes
#10

Each an every one of us has been … undesirable to others, more superior than us at that point in our lives.

But that is life : we are called to it with all the (huge, possibly eternal) risks involved.

Both sides, kindly try to reduce the drama and tolerate the very productive, even though the socially … less amiable, members.

Policing without lawful mandate does not make a “community” - this is a dangerous path, not just for Scala, but as a way of life.

PS; over years I have seen comments from more “sociable” leaders that pass the CoC but to me are "passive aggressive* - no better (arguably worse) that just “aggressive”.

2 Likes
#11

Just read the wiki of the project. It’s very simply to test your project with it without requiring it to be included in upstream and been taken care of by other people. I don’t see there is any sort of automatic elegibility whatsoever. I recommend to close this thread, Adriaan has already said everything there is to say. And all the one time posters can return to Reddit and Twitter, thank you.

Edit: Since the last sentence has been happily picked up as an opportunity for anger ventilation, and I don’t intend to contract its purpose by adding yet another riposte to the already way too long and IMHO futile thread. In no means is the statement to be scornful of new users who are of course welcome on this forum. It’s a statement regarding the deceitful beginning “I’m hesitant to bring this up, but…” which includes the calculation for the responses here of which, yes, many are rooted in a sentiment of “I have no idea what is happening / I don’t know what the back story is, but …” So please judge by yourself at the current count of 152 statements forth and back what actually happened. Apologies to anyone who felt personally offended as a “first time poster”.

4 Likes
#12

They did on multiple occassions for many years, let’s not whitewash them. However, most of the perpetrators left for haskell already. Scalaz & ZIO consist of different people now, the attack is misplaced.

6 Likes
#13

How welcoming and inclusive of you.

This is not a question of if a project should be added or not, it’s a question of why projects that were deemed worthy of inclusion are now being removed without notice or discussion for the contrived reason of ‘coc incompatible’

The Scala old guard repeatedly force the current members of the community to relive the past drama the old guard had with people who are not in the community anymore. It’s ridiculous.

15 Likes
#14

It doesn’t justify the actions taken. Adriaan haven’t clarified anything but only given his personal opinion on the matter.

I agree that maintaining the community build is a large investment but deliberately removing a very important project like zio without any warning nor even a pull request has been very dishonest.

11 Likes
#15

Ridiculous is that you think that anything is going to come out of this thread by just summoning everyone to jump to put their one liners claiming the end of democracy and so on.

If, as these one liners claim, their shouldn’t be a link between politics and code, then please do live your mantra, just clone the community build project, add the projects you wish, and run the build. All the technology is there to your avail.

3 Likes
#16

If you coddle the jerks, they’ll never learn not to be jerks. Productivity doesn’t excuse behavior: 3 humans of moderate skill have been besting the lone genius since the tools involved were pointy sticks - it’s kind of humanity’s MO.

This cuts both ways: the community doesn’t have to tolerate toxic individuals, but if someone is to be ejected individually for unacceptable behavior, or as whole project for cultivating unacceptable behavior, there needs to be transparency.

2 Likes
#17

@adriaanm

Lets pick this apart point by point.

In the past, we were forced to include these now-removed projects because too much of the eco-system depended on them. Now that’s no longer the case, we don’t feel they pull their weight anymore.

A large portion of the community depends on these builds per the last survey (Somewhere around 25% for scalaz, iirc, with the number unspecified for argonaut). At no point is it your prerogative to dictate what should and should not be included as a function of “pulling weight”. “Pulling weight” itself is nonsensical handwaving, with no definition.

Maintaining the community build is a large investment, and inclusion in this list needs to be earned, both on technical and social merit. On both counts these projects fall short of our bar: they have become a small island in the dependency graph, and the negative sentiment generated by a few very loud scalaz maintainers is damaging to the community.

To translate, you don’t like some of the maintainers, so you chose to play high school when you thought they weren’t looking. You’re an adult, Adriaan. Get over it. You do not get to dictate who is and is not community. Coincidentally you have effectively nullified the code contributions of the 2 most skilled women in the industry as well, one of which happens to go around speaking on Scala’s behalf. This is a misplaced attack of the pettiest nature. People were damaging, and have left. Typelevel dealt with the same thing. They are not being punished. Scalaz dealt with it, and they are. But the difference here is that you see an opportunity to kick a project you don’t like while it’s down on shaky terms like “CoC compatibility” and “community” arguments which are ill-specified and ad-hoc to suit your needs.

Of course we will continue fixing bugs in the compiler if these projects discover and report any regressions, but we feel the coverage of the community build is sufficient as it stands, and it would be unlikely that we won’t have already caught the issue thanks to the remaining projects.

Stable code has a habit of doing that. But thats not the claimed reasoning. This is all a red herring. The original point was Scalaz not being “CoC compatible”, which is not a technical reason. Nor are your technical reasons detailed in the eligibility requirements, nor was the fix symmetrically applied to anyone else forming an “island in the dependency graph”. Kind projectors is an island. Pascal is an island. Zio is on forefront of testing the compiler with new ideas, but it is also an island. None of your reasons stand up to any scrutiny.

Call it what it is. A bunch a maintainers left and you took the opportunity to try and “finish off” the project by excluding it from community builds because you have a personal vendentta against them. This is not ethical behavior for a leader. Pinging @sjrd to come see this bs.

27 Likes
#18

What are you talking about? I haven’t said either way weather there should be a link between politics and code.

I don’t think a mantra is really necessary here, it’s far simpler than that. This action is antithetical to everything the scala community managers have professed to stand for over the last few years, indeed since the original z cats drama all those years ago. Which is inclusivity and fostering of a welcoming environment. This is a pretty stark and unwelcoming message to the members of the community who happen to have found scalaz before cats or more recently have been interested in zio and drawn in by all the hard work John has put in there.

None of these people have anything to do with the ancient drama that is the genesis for this pr nor do they or should they care about it.

What they do now have to care about. Is the fact that the Scala core team is so dismissive of a couple of libraries they like, at best they will be apathetic to this and at worst it will make them think that they have to choose ‘sides’ and they already know and like the zio community so they will choose it. Resulting in an unnecessary and detrimental schism in the community.

Even if the “technical” reasons for excluding the projects where true. There is a strong argument that could be made that after all the healing work that has been going on between the cats and scalaz communities over the last 12 to 18 months, coupled with the fact that the antagonists are no longer part of the communities, leaving these projects in the community builds as a gesture of solidarity with these community building efforts is a course of action more inline with the professed goals of the community managers.

I think, unless there is a specific question directed towards me, I will make this my last comment on the issue.

10 Likes
#19

I am in no position to assess who is “jerk” or “asshole”.

But also not going to change languages or platforms because I might believe some people are.

Must say that, to me, censorship just because you can is dishonest and this is “passive aggressive”, not “nice”.

ZIO is an evolution in how functional programming is done and that is not going to be lost due to the debates by who is running the builds.

Surely technology allows for solutions to avoid the debate altogether: “Scala FP community”? :slight_smile:

1 Like
#20

I’ve got no stake in this decision as I help run F# from the Microsoft side of the world, so feel free to ignore the words that follow. But this looks like a decision I helped make in 2016 that I still regret, even though it’s all worked out and everyone seems to be happy today.

Back in 2016, we were heavily pushing the F# and .NET world towards .NET Core and a cross-platform by default world. You could argue we’re still doing that, and you’d be accurate, but back then .NET Core was missing a lot of stuff and it was kind of rough for early adopters.

The F# community stepped up and built the “F# SDK for .NET Core”, which among other things was a plugin into the .NET Core SDK itself. Our infrastructure around .NET Core was nowhere where it is today, and although we did our best, F# could be broken for arbitrary builds of .NET Core seemingly out of nowhere. But because the F# SDK could be built and updated independently of the .NET Core SDK, typically F# users would only be broken for about half a day or so.

However, this project only treated a symptom, not the root problem: F# wasn’t a part of the .NET Core SDK. So after lots of internal discussion and complicated technical negotiations, we decided that F# would be included as a part of the .NET Core SDK moving forward. Our reasons here were technical, not political - we thought the F# SDK was decent and we had a great relationship with its maintainer - but due to poor timing and communication on our part, we did not let the maintainer and broader F# community know about our decision until it was ready to ship.

This caused two problems. Firstly, the designators people had in project files were now incorrect, and unless they changed them, their projects wouldn’t build. Secondly, and more importantly, we lost a lot of trust in the primary maintainer of the F# SDK and a handful of other F# community members who supported his efforts. He had the grace to let that one go and completely forgive us after only a few short weeks, and we’re extremely grateful to still have him work with on shared interests, such as helping develop, maintain, and mentor newcomers to the F# ecosystem in the primary cross-platform tooling plugin for VSCode.

However, the damage that was done was far larger than anticipated. Only after about two years later have they been fully resolved. For two years, I would get bug reports from users saying that their older projects wouldn’t build anymore. Some people who really supported the F# SDK took a lot longer to forgive us than the actual person whose work was unceremoniously tossed to the side. I can’t prove this one way or another, but I wouldn’t be shocked if we even lost a few people from the community to other ecosystems. Some folks simply may not trust me or my peers at Microsoft to work harmoniously with the community again after this.

So, what’s the purpose of this unrelated story?

Unceremonious takebacks with no discussion or at least advance warning out of respect of the people involved is a mistake. It doesn’t really matter what the backing reasons is: policy, money, technical improvements, etc.

Please don’t take my idle thoughts here as discounting the difficulty inherent in a project like the community build, nor in the rich history involved with the projects involved and their maintainers. I also appreciate the desire to have some level of uniformity on the issue of a code of conduct (in fact, I’d love it if all OSS projects adopted the Contributor Covenant CoC). But as someone who approved a similar kind of takeback in a different ecosystem, I’ve come to regret that decision even 3 years after the fact. My advice is that someone kick off a private discussion between involved members and attempt to resolve this with the minimum goal being that nobody leaves the conversation feeling scorned.

19 Likes
#21

:face_with_raised_eyebrow:

1 Like