CoC-compatible Community Builds

Meta Discourse
104

Unfortunately, all communities are ultimately managed by both transparent and opaque processes. It would be wonderful if all decision-making in all settings could be entirely transparent, but as someone who has managed communities of varying sizes and purpose for a long long time, it just doesn’t work that way sometimes. Sometimes, discussions need to be had outside the public eye, in order to avoid potential for misinterpretation and/or drama. Sometimes drama, in the end, is unavoidable, but the drama associated with the decision-making process itself would be even worse. Sometimes, these discussions ultimately lead to nothing. Sometimes they lead to action where the root cause is opaque. This is always unfortunate when it happens, but it does happen.

These sorts of things serve as a stark reminder that the Scala community, as with all communities, is ultimately a vote of trust and confidence in the community leadership. If you choose to participate in the community, with all its attendant benefits and joys and opportunities, you also choose to trust that leadership to some extent. Trust in leadership isn’t really as required when leadership is making decisions by transparent processes (such as the SIP committee). Trust is needed for times like this, when decisions have to be made without the motivation ever being publicly known.

We as a community have to trust that leadership is a) only taking such clandestine steps for matters where it is truly necessary, and b) making the right choice, not just for themselves but also for all of us. That’s just part and parcel with being a part of a community. We’re not forced to do this; we can all walk away. But we choose not to because the benefits outweigh the risks involved. As is the case with all stable communities.

This is a delicate balance for leadership, too. It’s never easy to make a decision in darkness, and you’ll always second-guess yourself before, during, and after the fact. Transparent decision making is, in a lot of ways, easier! If you get something wrong, half a dozen people will come crashing down on you to explain it in painful detail. That provides a really nice safety net when you’re moderating a community: the collective wisdom of the masses helps validate or invalidate your own decisions, when they’re made in the open. Choosing to make a decision behind closed doors is not a choice made lightly, and it will always be second-guessed both by the maker and by community at large.

This is all very meta. Bringing it back down to earth…

I trust Adriaan, Seth, and co that this isn’t the top of a slippery slope that is implicitly feared in many of these responses. I trust that, whatever the reasons, they were worth it. They obviously knew this would set off this kind of a firestorm. They wouldn’t take that step lightly.

Anyway, I think it’s natural for us as a community to push for more transparency, but when community leadership assures us that there’s a good reason to withhold information, we really don’t have any choices other than to either trust them (as always), or walk away. I choose the former.

19 Likes
105

Some have asked for a way forward. I have a modest “mediation” proposal, tho I’m afraid I cannot find much fault with Lightbend. If anything, they could have articulated their rationale better for the benefit of outsiders who aren’t aware of the situation — who apparently are many? As it’ll be clear, I don’t think they owed many explanations to the abusers.

If Scalaz wants to regain trust (which isn’t clear), they have to figure out how to apologize for their past trangressions and avoid they happen again, till the other parties are satisfied. Honestly, if we gave suggestions, we’d get accused of meddling in their internal business, but since they asked, and since some outsiders think that’s a reasonable question: Scalaz could start by establishing any standard for acceptable conduct, and expelling offenders.

@djspiewak gave a great summary of the situation. I’ll reinforce/add a few points.

  • Including a project in the community build is a professional collaboration. Both parties have to be willing and act professionally.

  • A fundamental problem seems to be that even some current Scalaz members do not trust Scala’s technical leadership on the technical side. It seems some of them believe Scala should follow Haskell a lot more than it does, and fault Scala’s leaders for not doing so, to the point of not respecting them. Without some level of technical agreement, it might be impossible to collaborate. For instance, once in a technical discussion, Adriaan remarked that if somebody wants Scala to be Haskell (which the other had basically just proposed), shouldn’t they be using Haskell directly? To me, this is unobjectionable common sense; some Scalaz contributors have long been offended by this, and act accordingly. It’s hard to find common ground. Some of those people indeed moved to Haskell, but it’s unclear if the position has left Scalaz.

  • I’ve never seen Scalaz credibly condemn abusive behavior from its members. I’d say, therefore, they are condoning it, and should be treated accordingly: professional collaboration is impossible. Maybe some Scalaz contributors are well-intentioned but want to avoid policing behavior of their colleagues — “code is all that matters”. But who would want to collaborate with Scalaz, if they don’t guarantee professional behavior?

25 Likes
106

Seems to me @adriaanm and Co did what they had to do to break a collaboration pattern they were finding to be negative, and tried to do so with minimal fanfare. But what’s not clear to most people (including me, before reading this thread) is that the actual technical consequences are probably not significant.

I’ve got much respect for so many of the leaders in this community, but it seems as though some may need to decouple their work from others. To the extent that it’s possible to do this without impacting the rest of the community, it’s probably not as big of a deal as it first seemed.

7 Likes
107

This is a false dichotomy. The third option is the one most of the posters in this thread have been pursuing: apply non-abusive pressure for greater disclosure.

In this case, we found that:

  1. The CoC violations were in response to change requests.
  2. The removal was likely justifiable soley on the basis of slow turn-around times for these change requests, without the vague CoC accusation.
  3. There is at least some lingering “Benevolent Dictator” culture remaining, as our concerns were treated with some really patronizing responses.

This is almost correct. Unless the community is lead by a Benevolent Dictator, decisions need to be justified to the community. Consensus is sometime easier to achieve in private, but the decision still needs to be presented and stand on it’s own merits. If some of the reasons can’t be shared, the rest need to be sufficient.

Both the response, and that the vague CoC accusation could have either been justified in the PR or omitted entirely, are indicators of a problematic attitude toward the community, and exceedingly poorly timed. The migration to Python 3 was difficult in no small part because of a lack of trust between the community and the leadership. This is not a good time to be wasting trust instead of building it.

5 Likes
108

This is the most straight-forward and comprehensible explanation I’ve seen for this change. And it’s totally legitimate! The contributors get to decide what they spend their time on, it’s just a fact.

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

It’s hard to see what exactly you have in mind here, or what these projects could do to remedy the situation. John’s attempt to engage constructively in a ticket was immediately closed and locked.

Overall, the message I’m getting is that the community build maintainers see any and all interaction on this topic as a complete waste of their time, all downside and no upside. Ok. But if I may be permitted to go “concern troll” on you, there will be consequences to doing things this way in terms of how people view Scala and its community. There are trade-offs in everything, and in my opinion this could have been handled in a different way to make better trade-offs.

6 Likes
109

I think it’s more like, if a company sponsoring free food suddenly decided a smaller but significant subset of the conference population was suddenly not allowed to have free food, people would have reasonable cause to be upset and question if they want to continue attending said conference.

I fully support Seth and Adrian’s right to remove Scalaz, but let’s not pretend it doesn’t hurt Scala overall. I have and continue to be in leadership positions at companies that make decisions on how much and when to use Scala, and this erodes some of the remaining trust I have.

1 Like
110

New poster here, and I don’t really want to act like I’m picking side.

Anyone familiar with the Antd Christmas drama? This is like a far lighter version of that,
but yet it feels like an earthquake in the community.

Maintaining a famous OSS project is hard. Theoretically no one can tell you what to do,
but people have expectations. Breaking them without transparency will cause issues for sure.
Failure to either realize that beforehand or after the damage does not help resolving the issue at all.

Context: Antd, a UI library, introduces a change to make every UI component Christmasy that only triggers on Christmas, without informing anyone. And it happens. A lot UI were broken, and many developers are affected (even fired).

2 Likes
111

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
112

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
113

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
114

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.

115

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
116

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

117

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
118

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.

119

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
120

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
121

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
122

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.

123

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.