What actions can be taken so that the community build supports ZIO and Scalaz again?
6 Likes
I think we’ll probably need to pause until the changes to the Eligibility docs have been made.
If those changes don’t sufficiently clarify the criteria ZIO and Scalaz need to fulfill to get back in, asking for clarification after we have this information will be much more productive than pressing the issue now.
1 Like
What if Scala Steward or something like it would open or update a PR in a downstream project every time a new Scala nightly was published, and if it introduced any failures there would be some way of aggregating them (each project might have a different CI so it wouldn’t aggregate the errors, just the failed projects for a given release)
2 Likes
There is no plan to exclude projects that have no CoC or weak CoC, if those projects haven’t been an actual source of trouble.
Ah, so you do admit this has nothing to do with a codified law but rather just the fact you decided what projects were trouble.
You realize this is a horrible precedent and it makes all of Scala look bad, no? We should all be embarassed.
2 Likes
Nothing wrong with technical disagreement on an issue — I’m sure we all did. Debate is essential. But handling it professionally is also essential. Once a debate ends, can you move on, or will you bear a grudge and act on it? Scala just can’t drop subtyping (or even inheritance).
EDIT: let me clarify what’s above is indeed just a question — I don’t know the answer.
As a separate question, John’s very good at spinning and selling his ideas. There’s nothing wrong with that, and it’s not remotely a CoC violation, but if you’re trying to have a debate, the spin makes it harder to get at the actual content.
Scala has a CoC itself (and Seth is one of the moderators who enforce it). While e.g. specs2 has no CoC, nobody ever suggested specs2 maintainers violated Scala’s. That’s very much not the case for Scalaz.
This whole thing is clearly looking bad, but not because I doubt the actual decision, or because in Seth’s place I would have known how to do things better. The way it was made looks bad. But had this decision been done the best possible way, I’m sure there would still have been protests — which is probably why they did not try to go a different way. The only difference is that, apparently, this looks bad to people who did not have a former opinion (not that I can read their mind).
Still, it’s disappointing that the Scala CoC has been unable to block the underlying abuse earlier, and I have no idea how to make this meaningfully different. Time ago, somebody publicly suggested me as a less biased moderator. I admit I never got to replying, but the idea honestly scared me: that of the moderator is a pretty thankless job that puts you in the middle of multiple firing squads. In this thread, I volunteered some examples from past discussions, since people kept asking, and I already regret that.
8 Likes
The point of a code of conduct is to make it clear what constitutes unacceptable behavior.
Saying “I will/won’t do this” is not, ultimately, what indicates behavior; it’s the actual behavior.
All that saying “I will/won’t do this” does is provide a reassurance. (Analogy: it’s a comment, not the underlying type!)
In practice, the observation and thus the expectation is that any random project, CoC or no, has maintainers that conduct themselves professionally and politely.
In the face of direct evidence that this is not the case, or in the face of a pattern of past behavior that changes the expectation from positive to negative, a CoC can help motivate trying anyway.
I expect that this is all that the eligibility rules will say: we will give you the benefit of the doubt; a CoC can provide reassurance as long as it’s followed and can motivate us to try a bit longer if we hit some rough patches; but at the end of the day, actions speak louder than words.
5 Likes
The point of the no aggression / don’t insult / no trolling rules is to avoid precisely the kind of attitude that Tony displayed here in his only post.
He made an astute point as well, and he set out a principle that is good to know, and none of that required the emotionally-laden, mildly personally disparaging phrasing that he chose to use.
If he said, say, “Crikey mate, that’s not the least bit bad in my book. But I’ll try to have more of a care next time round”, and there was any evidence that he was trying, that would be very different from what I understand his actual position to be, which is a principled one that such rules are counterproductive and that he won’t be bound by them.
I think this is a very good point. People have been operating under the assumption that being included in the community build is a good thing. Sure, there’s some modest level of visibility and recognition that goes along with it, and you do get a nice little bit of a heads up when you might need to fix something (maybe with a handy bug report locating the issue(s)!), but personally for code I’m responsible for (I’m not responsible for any widely-used libraries, but if I were) I’d rather avoid the extra expectation of responsiveness unless the compiler was going to stomp all over my code every update without it.
5 Likes
The question here is whether or not the community build should include Scalaz and ZIO; I don’t see how any of this is relevant if no CoC violations are involved. Scalaz and ZIO do not set the direction for the language, they are projects that use the language. These are entirely separate matters.
1 Like
I guess you think that it is altruism. I think it is egoism( steal attention ).We have misunderstandings. This is CoC violation. We even might not know that CoC exists. But if we have different understanding of ethics we will not understand each other. I know only one way to work in such case: Pay or obey. Otherwise it is a way to dramma.
I don’t think it’s a good idea to have eligibility criteria for the community build that promise the community build team will adopt the project in the community build if those criteria are met. Having the criteria as guidelines seems good, but if a project turns out to be more hassle than it’s worth, it shouldn’t be in the community build. Let’s not make more out of the build than it is.
3 Likes
There’s a whole section at the end of that document which covers “We may not want your project”. Setting minimum eligibility criteria is an orthogonal concern, and a very good thing in terms of transparency.
2 Likes
That would be very cool.
A closely related possibility for projects that:
- aren’t included in the community build, for whatever reason
- but want to help catch Scala compiler regressions and/or get early notice of new incompatibilities
is for those projects to add “latest Scala nightly” to their own CI matrices. there is some past discussion on this at provide guidance to project maintainers on including “latest Scala nightly” in their CI matrices · Issue #648 · scala/scala-dev · GitHub . As you can see it’s an old ticket, but it isn’t really something that critically depends on central action from the Scala org, it’s something that individual projects can do on their own initiative. (The ticket would be a good place to swap tips & knowhow.)
The considerations are somewhat different depending on whether you want to test against a Scala release series that has frozen binary compatibility (e.g. the 2.12.x series for a while now), or a release series that hasn’t yet (e.g. the 2.13.x series until 2.13.0 comes out, though we’re already trying very hard to avoid any further bincompat changes).
Once bincompat is frozen, you can pull all your dependencies from Maven Central and just compile your new code with the new compiler.
Before bincompat is frozen, all your dependencies have to be built with the compiler you want to test. That’s when dbuild is so important to have. (Or some other tool that builds everything from source, such as Bazel, Pants, or Fury.)
This thread has become very lengthy and is devoted mainly to the community/governance issues, so for further technical discussion in this vein, it might be better to move to a new thread.
9 Likes
Come to think of it, since nightly is well, nightly, if you want to build against it you don’t need something like Scala Steward, you just need a CI that supports scheduled builds.
5 Likes
So, what’s the meaning of this storm?
I’ll keep this brief and unilateral.
Agreed, and I empathise with and commend you on your holistic view and approach.
Sounds to me as someone who’s states that the main purpose of his/her/their life is to serve as a warning to others.
Which I (privately) believe is a commendable and reasonable purpose as long as others are not enforced to react on the warnings expressed.
And thus the Hero in me, protecting the underdog, leapt into action, not knowing the depths of the divide.
That one got the room quite hot, my apologies, scalaz is not my fight, not my level, I leave that to the omnibenevolent.
So let me back-track to the origin that got me on this forum, and leave the realm of organisational names.
I haven’t seen John here while he was so passionate in his request for an explanation.
I haven’t seen Seth communicate with John anymore, or anywhere, still he committed to the removal of scalaz and zio.
I believe both think the other should apologise for something the other did, the question is what and how we can help them do so?
Because as a Scala programmer, professionally, I’m not interested in the why.
This thread is dead-locked in carelessness on its semaphores: John and Seth.
But I extended that lock to you all in words, and included myself in spirit after being asked to explain myself.
Everything in this comment was written in denotational language.
I principally crafted this comment with the intend to remove all implied language.
Even though in reality this is an impossibility.
If I have only one thought adding value at this forum, it would be that thought.
The physical act of clicking Send thus publishing this comment scares me … but I’ll do it anyway.
I was directed to this thread from an issue I opened on Github, which asked two questions:
- Why were the projects (ZIO, Scalaz, Argonaut, etc.) removed from the build, particularly an explanation of the commit message, “Removed CoC-incompatible projects”
- What steps would be necessary to get some or all of these projects back into the build (i.e. eligibility criteria)
I was disappointed when the thread was closed without explanation or resolution, and I was redirected here. Although I have not read every word of all 230+ posts here (I commend those who have!), I cannot find any answers to these questions from official project maintainers.
While disappointed, I’m still very grateful to Lightbend for sponsoring the community build, and I think it provides tremendous value, helping to ensure a stable Scala compiler for users worldwide. I think the build provides even more value to the Scala community when it includes important projects (for example: Scalaz has 1 million downloads a month; ZIO pushes the type system in novel ways at the intersection of subtyping and FP, and has already identified a number of issues for Scala 3).
More than that, I’m personally grateful to Seth, whose positivity, work-ethic, generosity and commitment to the betterment of the community are evident in his every interaction; and to Adriaan and others whose important work at Lightbend have helped make Scala the production-worthy choice that it is today.
I believe that Scala-the-language belongs to all of us who live and breath Scala, and who have chosen to devote our careers and sometimes our personal lives to the language and ecosystem. I also believe that when companies sponsor work inside the official Scala organization on Github (scala), they are assuming the position of stewards of the Scala community.
Quite unlike being the maintainer of a personal or commercial open source project, I believe that being a steward of the community carries with it great responsibility.
In my opinion, being a good steward of the community means, first and foremost, making decisions in a transparent and equitable fashion, which can withstand close scrutiny; it means making decisions considering only the community as a whole, without consideration of the interpersonal dynamics that often do (and should!) drive personal, third-party and commercial projects; and it means conducting oneself (in that venue) as a consummate professional, including, of course, sometimes making hard choices that not everyone will agree with.
Looking back at the removal of these open source projects from the community build, my own Github issue, and the followup in this thread, I personally believe that there is ample room for improvement in stewardship of the Scala community build.
This is not a knock on anyone, however. It’s very important to recognize that we are all human, and part of being human means making mistakes and learning from them; and moreover, that there’s no guarantee that anyone participating in this thread would do a better job, if they were in the same circumstances and had the same life experiences.
Moving forward—and that’s precisely what we must do, because it’s too easy to remain fixated on the immutable past—I hope that answers to questions such as the ones I’ve raised will eventually become clear to all; I hope transparency and equitability will improve; and I hope and trust that all the well-intentioned people working for the good of the community will learn from this experience, and set an example for other communities of what great community stewardship looks like.
I encourage everyone to lay this issue to rest; and I thank so many for taking the time to share their perspectives on the way forward. Although emotions flared at many points in this thread, it’s obvious a lot of people care deeply about improving the Scala community, and at the end of the day, that is a very positive thing.
P.S. I would rather build the future than argue about it, so I won’t engage further in this thread. Find me at https://github.com/zio/, ZIO’s new organization (unaffiliated with any third-party organizations!), at the new ZIO chat room https://gitter.im/zio/core, or at my personal blog, http://degoes.net. Happy hacking!
28 Likes
people need to make a living from skills that they invest into the scala platform, CoC is not related to scala or people’s efforts in this direction, please stop this
2 Likes
Hey John,
I read your message carefully and agree with the spirit of its contents.
The issue grew though, during your absence, I have just two concrete questions:
-
Do you represent the scalaz organisation in this?
-
What did @SethTisue say when you complained with him personally about his single unreviewed commit?
Sorry for the directness, but we would like to close the issue, it has been going on for too long.
People are emotional here. Some are scared. Others just irritated. You can cut the tension with a knife.
Note also, the world outside of the Scala community is observing this.
If you read the message carefully, you presumably noticed that John said he won’t engage further here, along with clear reasoning for why.
Since no answer John could give would actually close the issue, I think it’s quite appropriate to respect his declaration.
4 Likes
I agree,
But didn’t understand: did he mean he would not engage at the Scala contributor forum?
Perhaps there has not been a private talk between Seth and John, all this time?
Which (in my private personal mind) would mean that Seth has not apologised for the single unreviewed commit yet.
Let me ping John, and ask him more privately.
I’ll report his answers back.
Seth and I applaud ZIO’s decision to move to a new org, and we are open to its subsequent re-admission from its new home, especially in light of https://twitter.com/jdegoes/status/1123614427582832643.
Based on the feedback in this thread, we’ve updated the eligibility criteria of the CB to more accurately reflect its purpose and how it is managed.
11 Likes