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”
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
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
Fair enough. Just be careful when trying stuff like that. Idioms in English are like monads - they don’t compose 
.
They also don’t really decompose, “Silver bullet” can’t generally be used to refer to parts of the software engineering problem laid out in the MMM, only the whole. So the reference you tried to make didn’t connect and sounded, at least to this native ear, less like a call for better communication, and more like a very confused call to violence. Luckily it was sufficiently nonsensical that the general reaction appears to have been confusion, rather than concern.
At least for me, it’s not about scalaz. I don’t use scalaz, I don’t contribute to scalaz, I don’t particularly care about scalaz.
What I object to is entering an accusations into the public record, with no opportunity for appeal, and justifying an action based on that accusation. That an appeal would most likely fail is entirely beside the point - process matters.
The most frustrating part of this fiasco is the condescending “put up or leave” attitudes from maintainers and SIP committee members. How that’s not in violation of the CoC, I haven’t a clue.
The second most frustrating part is the addition of the allegation of CoC violations was entirely unnecessary. The PR would have stood on it’s own merits - nobody is disputing their right to remove a project based on ROI.
6 Likes
I entered the Scala community past the drama that apparently unfolded somewhere in the the past few years. And I have no idea who did what and why.
I really think it is a shame that ZIO is kicked out of the community build. (I leave Scalaz out of this as I do not have any experience with it, nothing more, nothing less). I think ZIO is one of the better examples of how functionally pure code can be combined with object-oriented features. Something which Scala has been aiming for since the very beginning.
John has shown that he is welcoming new contributors, helps with educating developers using workshops and talks, and also has shown that he is willing to work towards a a more united community. He has asked why did this happen and what could be done to get ZIO included again. Yet, I have not seen any response back on how to make this happen.
It would be nice if we could get past the name calling, and bringing up the past, and have a discussion on how to improve from here, regardless where we came from.
11 Likes
Sorry, I’m not trying to insinuate that anyone is lying here. All I’m trying to do is understand the details behind the incident and what could be done to revert the change. This information is being withheld and, as it stands right now, there doesn’t seem to be any path forward for re-integrating Scalaz/ZIO in the community build.
Its a big change that’s out of left field. Doesn’t it make sense to get some clarification? At the very least so that we can learn from the mistakes?
3 Likes
+1 and this github issue seems to go against the narrative that the community managers are trying to push that the maintainers are hard / abusive to deal with in regards to the community builds.
4 Likes
I’ve not read all of this thread, but my interpretation is that the maintainers and SIP committee members are being reasonable here.
I don’t interpret their actions as “put up or leave”, I interpret their actions as “the grief/hassle of interacting with some folks in the scalaz community isn’t worth the marginal benefit of keeping scalaz as part of the scala compiler automated regression test framework”.
Kind regards,
Rob
4 Likes
So let me get this straight.
The Lightbend maintainers removed a library from their open source regression test suite.
The given reason was that collaboration with the authors of said library has been straining, due to the lack of any code of conduct on their part.
Where’s the problem?
It seems much of the emotion is due to @emilypi’s characterization of the community build as:
But that seems to be a widely incorrect characterization — unless I am missing something. Just looking at the project’s README, we can see the scope is much narrower:
This repository contains configuration files that enable us to build and test a corpus of Scala open source projects together
(Emphasis mine.) In other words, it’s just an arbitrary corpus of open source projects, never meant to be representative or an official endorsement in any way.
That would explain why the maintainers did not feel like a strong justification was needed.
14 Likes
That is not a list of most important anything. Nobody claims that. Either you misunderstand the purpose, or are purposely dramatizing.
It is a list of useful things, for a specific purpose.
1 Like
Indeed.
And now the title is “Coc-compatible Community Builds” and not called anything about “Scala community”.
So people excluded do not feel excluded from “Scala community” by a change in some build scripts.
Surely there will be other ways to build Scalaz and ZIO because they are valued by many.
If we think this way then there is no requirement for fairness or “community review” anymore which makes it easier to swallow for the major contributors.
Right?
So it looks like it can rest here.
1 Like
The Lightbend maintainers removed a library from their open source regression test suite.
Is Lightbend the sole owner of https://github.com/scala/community-builds?
3 Likes
You really should read the whole thread before making a judgement. Here’s a sampler:
Since I have been mentioned in this thread, I will chime in with a brief word. It should go without saying, but just to be sure: this is a personal opinion that does not engage the other employees of the Scala Center.
I stand by and support the actions of @adriaanm and @SethTisue in the community build. The community build is mainly an extension of the CI for the compiler team, and hence the compiler team has every right to add or remove stuff from it, at their entire discretion. I wish the commit message had been either more informative, or less informative, in order to avoid the drama that this thread obviously became; but that does not change the fact that I do not see any problem with the code changes themselves.
For any justification of my opinion, please refer to @djspiewak’s answer at
which I wholeheartedly agree with, and I couldn’t have said anything any better than he did.
12 Likes