CoC-compatible Community Builds

As I see this thread continue, I find myself increasingly convinced that the decision here was less rooted in reason and more driven by emotion. So I will respond to individual comments by @adriaanm:

enough is enough. If you want to be part of the community (build), act like it.

With all do respect sir, many of us here are adults and resent being addressed as if we were school-yard children. We are all here to have an honest debate, and as a “community leader”, once again I respectfully ask you to “act like it”. In doing such, I recommend that any calls-to-action be direct and specific. That includes spelling out any infractions in detail. Otherwise, many of us will be forced to conclude that no actual infractions ever occured.

I have not negatively singled out individuals, and I won’t start now

That’s fine. We aren’t expecting you to name names, but if you want behavior X to stop, you must state what X is.

Our trust and confidence has repeatedly been damaged, and you’re not just
going to get it back through lip service.

We aren’t asking for lip service. We are asking for the honest truth.

maintaining the community build involves asking people to make changes to
their code/build definition when they break the build. These interactions with this > particular group of people often turned vitriolic on the slightest disagreement (as > you can see in this thread)

@adriaanm, at first, I see you making a fair point as I can fully understand that collaboration is required during build breakages. But, then you cite the disagreement around your response to the conflicts as the reason for the response? Isn’t that reasoning: circular? And without more technical details, without giving out names, are we supposed to assume that your requests for code or configuration changes were reasonable?

You’re blowing this out of proportion.

Once again sir, the condescending tone is really disappointing. Sure, there may have been others that have been rude, and talking to those people individually would be the proper response, not venting out on entire code-bases used by large teams that have nothing to do with those personal conflicts. And to me, it seems me the “community leadership” is actually “blowing this out of proportion”.

You started this thread, with dubious motives to say the least.

That is hardly what I would consider a mature response. So, no further comment on that.

You’re on a personal crusade. You’ve edited it out now, but just a few hours ago > you were suggesting I have mental health issues.

I certainly would prefer to avoid ad-hominem attacks, but one word advice: repeating them does not help your case, to say the least.

I must say, I deeply question the leadership that has been on display here, I question its motives and I question its ability to introspect on the impact of its decisions and make corrections in the face of controversy (which if this thread is any indication: certainly qualifies as a controversy). I actually believe @adriaanm and @SethTisue believe they are acting on the best interest of the community which they preside over, but I am not seeing much evidence that they have the means to do so. Sure, this is clearly open-source and non of us are entitled to make any demands. But frankly, neither are any of its so-called “community leaders”, since an open-source project is not entitled to a user-base.

10 Likes

I think this is an important piece of context that has probably not been clear enough in this discussion. The maintainers of the community build decided to remove some regression tests from their test suite of third-party projects because they decided that the return was no longer worth the investment. Nobody is being ejected from the community or denied access to certain tools or whatever.

But … isn’t this exactly what is meant by “blowing this out of proportion”? Nobody was venting out on entire code bases or teams or communities. Some regression tests were removed from a test suite, without making big announcements about it or creating a show or calling out any individuals or groups of people. The only thing that could possibly be said is that the commit in question could have been worded differently. But even then it’s still a fact that Scalaz projects don’t have a Code of Conduct which is even remotely compliant with the Scala CoC and they are very proud of it, so what is the problem?

9 Likes

I don’t believe that the community builds are intended to be, or should be seen to be part of an effort to catalogue and categorize community projects, and painting the removal in that light seems harmful to the discussion.

12 Likes

The problem is misunderstanding.
To say the truth I prefer not to work with the people who do not understand code of condact.

Yes, it is true I have trauma, and the result of it is allergy to yellow argumentation. I can control myself, but if I can I try not to work with people who motivate me with “good words” just to prove me that their desires are more important than my.
I can only repeat. Ok, you are right. It is just enough.

I wonder how it can be overcome. But It seems, that if people have different motivations and ethical codes it will be impossible.

I think this is a bit disingenuous. The project is entirely test suites. This isn’t just some CI on a standard project; it is the core intention of the project.

That is not what my concern is and i haven’t seen anyone say as much in this thread.

My concern is that, yet again, we see technical decisions surrounding important tools in the ecosystem being made on an emotional whim. No scala developer benefits from that.

You can cut the tension in this thread with a knife. I think that speaks to how damaged our community is right now.

Again, i don’t think there is a black and white outlook here. Clearly @adriaanm has had a difficult time working with certain scalaz maintainers and is well within his rights to make whatever decision he cares to. But i also see a community leader talking down to concerned users and defensively reacting to criticisms.

There can be common ground here. What i expect from someone as influential as @adriaanm is a professional means of providing a resolution. That has not been shown in this thread. Many users have asked for what can be done to reverse the decision, and have even offered helpful suggestions. But those questions have not seen replies. Instead we are being treated as if our concerns are meaningless and not worth discussing.

1 Like

So, It is obvious that they really have tried to solve it.
I personally really want to find a silver bullet.

Whoever claims that all the projects in this list - https://github.com/scala/community-builds/blob/2.12.x/configs/project-refs.conf are more important than scalaz should provide a better excuse for whatever is going one behind the scenes.

1 Like

Im not sure i follow? Yes that thread is painful to read through, but the issue here is not with the establishment of moderation or action taken 7 months ago against specific individuals. This is a decision made to remove scalaz from the community build regression test suite with no path to resolution.

I am going to chime in here, not that I don’t necessarily agree with how things are handled but I am just giving an opinion here.

Firstly, it appears (and I think that this is the area that people are greatly over dramatizing), that being part of the community build is a privilege, not a right. Lightbend is spending its own money, time and effort free of charge for this build. In fact I am getting a general feeling that this post is more about venting and it being a “last straw” rather than reflecting the actual impact of what happened. I mean on the technical side of things, nothing is stopping Scalaz from either forking the repo, or just adding a hook to their own repo whenever a new Scala version gets pushed (after all, its just code!).

The community build is also in unique position where the maintainers of the build have to work with a lot of projects, which means having to work with a lot of people and there being a lot of human interaction.

I can definitely agree there is a lot of baggage in the air when it comes to dealing with Scalaz people, and the community itself is unique in this respect. I mean even have the case where one of the projects most prolific member has 60-70% of his public tweets are equivalent to “Scala is shit” and “I am glad that I am not coding in Scala today” (which is not a one off event of letting out steam, this has been going on persistently for years). Now its also true that the person isn’t really contributing code to scalaz anymore however he is still (for better or for worse) one of the public faces of scalaz and involved in the community there. This is only a specific example, the general sense I am trying to highlight is that certain number (not all!) people associated with Scalaz community communicate in a way which gives the following impressions

  • Denounce Scala constantly, sometimes to the point where they question the technical competency of core people involved in Scala, i.e.
  • Holy crusades mentality, i.e. saying that a certain set of Scala core maintainers need to be “expunged” or “expelled” because of bad blood that happened in the past (which everyone is still trying to get over). This thread is actually kind of an example of this
  • Over sensationalizing/getting defensive when motives are questioned, i.e.

None of this criticism is constructive and telling people that they need “mental help” is just putting salt on wounds (as well as completely off the mark unless your aim is to really piss someone off).

At the end of the day, the community build is a free of charge effort that is done by Lightbend. If the people working on the community build consistently have negative interactions with certain members of either Scalaz or the general Scalaz community, they don’t have to continue interacting in such a way, i.e. just like the Scalaz people are under no obligation to change their code of conduct or change the way they handle their members (or their behavior); core contributors of Scala are under no obligation to have to have to persistently deal with (what they see) negative interactions all of the time.

Honestly the impression I get is that the core Scala people are getting tired of interactions that are continuing to happen and just don’t want to deal with it anymore. I can’t speak for @adriaanm but it seems like he has had enough (just like other people have).

This stuff has been boiling behind the scenes for a while and the only way things will change is of people change their behavior. Unfortunately it seems people don’t want to the change their behavior, so this will continue to happen.

I suspect if you want things to change, then people need to change or their attitudes need to change or the communities attitudes need to change (which is highly unlikely)

The only solution I see is is to avoid contact which is the premise of the original commit. People from Scalaz have suggested codifying this in rules on Scala side however this has already been tried but more importantly the areas where this issues happen is not an area where anyone from Lightbend/EPFL have any control over (but crucially its still an space where people have to be part of to do their job).

This is why people often ask for compatible CoC’s btw, because just like Scalaz doesn’t have any legitimate right over how people interact in the various Scala repos + Reddit/chat channels, Lightbend/EPFL doesn’t have any legitimate right about how Scalaz people interact in their personal twitter/ scalaz related repos/chat channels. It is why typelevel asks for compatible CoC’s (if possible) for projects that want to be part of the typelevel ecosystem, they don’t want to deal with this drama (and there is none of this drama when EPFL/Lightbend people interact with prominent/public typelevel members)

14 Likes

I don’t really like painting the picture that the entire scalaz contribution network can’t be worked with. I get that there’s some bad blood between specific individuals, but surely there are people on both teams that can work together on a resolution? Why should the actions of a few people cause a decision that impacts thousands of users? How does that impact future decisions for other major libraries in terms of scalaz support?

One suggestion in this thread was to have a representative from the scalaz contributors to work with lightbend. That seems pretty reasonable all things considered.

1 Like

Because those specific individuals also tend to be the most prolific members/public image of the community. Look at this this way, another thread was referenced in where a prolific member of Typelevel stepped over the line in communication on his twitter. He ended up making the decision to step down from his position and from the typelevel community because he saw how damaging it was.

So the reason why “the actions of a few people” can have such an impact is to put it bluntly, they have a lot of influence, they are involved in a lot of online communication and they generate a lot of drama (unneeded or otherwise)

I don’t think this will change much

4 Likes

I think it was obvious.

They just cannot effectively communicate.

But what does it matter if they do not understand each other and blame each other.
It does not matter who is right. It just does not work.

Why not? Seems to be the root of the problem. There are many people that write code for scalaz, surely not every one of them are unable to be worked with.

We still have no insight as to what actually triggered the action. All we know is that @adriaanm had some sort of interaction recently that triggered this response. How can we sit here and say that response is appropriate without any further information?

It is just disheartening as I’m left wondering what this action will lead to down the line. This is a regression in the technical sense and it sucks to see that decision made in a blackbox.

It was not and the rest of my post indicated why i felt that way, but ok.

Its not recent, its something that has been happening (and building up) over years

3 Likes

Actually you may be right. But I can easily believe @adriaanm because I have such experience when bad communication can stop good process.
And I do not understand why I should not believe @adriaanm and @emilypi. They both say that communication is terrible.

1 Like

I’m pretty sure you’re being patronizing, and possibly making a joke of mental health issues, but since “yellow argumentation” isn’t an English idiom AFAIK and gives zero results on Google, I figure you should have a chance to explain yourself.

I follow this debate quite a while… Try to read it from a totally objective perspective without emotions. What part of this problem is final and can’t be solved?

If you are a maintainer for a free and open-source repo (like the community builds), you have the right to choose what code can be in it. They choose scalaz should go. This means nothing. If scalaz want, they can start/build a similar repo, and offer resources to build their project against the most recent scala compiler. (They can fix things too in the core scala-lang if they found bugs.) Why this is a problem in the technical perspective? They can’t do this? Is there any blocking issue why it can’t be done? (I think the maintainers should freely choose where they want to make an effort. If they don’t want to make more effort in the scalaz ecosystem/community maybe they will lose valuable users, but this is their choice.)

Every commit is revertable. Maybe making a big drama is sometimes needed to rise up some careless ppl. Maybe this is what needed for the scalaz community to unite against the bad communication/attitude, and separate the “good technical skills” from the “good communication skills” and move members where they belong. There are several blog posts about how non-programmers could help maintain repositories.

I still think that moving scalaz without any announcement was a not so mature idea. But I can understand why this happened and can understand why a lot of ppl feels why this is super bad. I think this is bad too. But before you choose sides you should understand both sides without emotions. This “drama” thread totally prove that beside most of us trying to be as professional as we can we are still humans with feelings.

So maybe it will be an unpopular opinion, but I think the community-builds and scalaz maintainers should both communicate better. And the others should stop throwing stuff, and should stay calm and try to solve the problem instead of making this worst. (Solving can be from leaving the language bcs of “unnecessary drama”, to attending as a scalaz<->community-build connector and try to actually help to solve the situation.)

Please stop arguing and try to reevaluate the situation from both ends and try to solve this!

4 Likes

Excuse me, it is my mistake.
It is play of words with yellow newspaper

Actually I can say that any CoC violation is bad. But it is good example of "yellow argumentation”
:slight_smile:

For example, I think

  • If you have trauma to deal with, seek therapy or a psychiatrist.

Is very, very, “yellow”.

You can count likes amount on this discussion. It is amazing quantity.
So to say the truth I think that discussion is yellow too :slight_smile:
If it were my work I woud be crazy :))

Of course there are very interesting thing. But the most amount of sense is the desire of people that even are not involved in the scala - scalaz process.

1 Like

I wish SIP proposal threads (that affect the future of Scala far more than any community build library inclusion) will be as “popular” as this thread.

6 Likes