Sorry, that sentence was poorly constructed. I had intended that, if the reference to CoC violations was omitted, there might still have been a discussion, but it would probably have been a boring technical discussion about the relative maintenance time spent on each project.
It sounds like a pretty strong argument along those lines could have been made, as I doubt the vitriolic responses @adriaanm referenced were paired with quick response times for fixes.
Hindsight is, of course, 20/20 and it’s all moot now anyway.
I just want to know what events lead to this decision. If that can’t be made public, then please just lock the thread. It’s obviously been painful for everyone involved, and without any payoff in sight.
Nice try patronising everyone into being included in your “we” and singling out a black sheep “you”. Surely skillful presenting yourself as the victim here.
The SIP process lives and dies by our ability to trust the people involved in running it, so their behavior absolutely reflects on the confidence I have that participation in that process means anything.
If the SIP Committee members have a pattern of autocratic behaviors outside the SIP process, why would I expect anything different within it?
The SIP record is there for you to scrutinize. Meetings are recorded, notes are taken and discussions had in public. When I’m wrong, I’ve accepted that and fixed the mistake (for example, recently, regarding the deprecation of package object inheritance, which I reverted).
I find it interesting that you’re bragging about your ability to admit mistakes considering you have dismissed the notion that you could have possibly had an error in judgment here.
I have very little confidence in your self evaluation skills after reading your replies in this thread.
I’m not against threads being locked (as they can be unlocked - I’m much more against evidence being destroyed, i.e. comments being deleted), but I suspect it’s likely that locking this thread would be even worse (censorship).
All that is well and good, but not sufficient. Records are only as trustworthy as the people making them, and asserting that justifying a decision using a vague reference to CoC violations doesn’t reflect on your credibility is naïve.
You had good reasons this time, no argument there. The idea that burying those reasons behind “trust me, they’re bad” doesn’t hurt your credibility is likewise naïve.
What reassurances can you give me that a persistent person with a minority opinion won’t be excluded from the SIP process because of unspecified CoC violations?
Maybe that’s true. I don’t see that here. Or maybe you don’t see that what you did wasn’t nearly as problematic as how you did it, and what it says about how you may solve issues in other contexts.
And just to head off misunderstandings: the CoC is a good thing, and it will remain so if it’s applied with transparency.
I would like to add that not only were responses defensive, in some cases they seemed outright hostile and personal, and hostility seemed extended to the community at large - or at least any community members with the temerity to request clarification.
Like many I don’t want to have to follow discussions of this sort but have no choice since, like many, I am affected by the outcomes, hence appreciate transparency.
EDIT: As @morgen-peschke above rightly put it, as a community member, the importance of knowing that a transparent process exists when it comes to management of community projects cannot be understated.
Let the record show, this is isn’t something @djspiewak wrote. Instead,
TBH, that’s not likely what motivated Seth to remove Scalaz from the build. As evidence, he had maintained Scala 7.2 in the build for 5+ years, and willingly added Scalaz 8 and ZIO to the build, recently. At this point, we’re probably venturing off-topic.
Personally, I think the storm of reaction and associated emotions warrants a statement from the Scala Center’s board members @tpolecat and or @bvenners, as they represent the community. I employ others to be reticent in their communications. Whether we like it or not, politics is an integral part of any strong community. As are due processes for managing accountability, responsibility, consultation, and information.
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.
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?
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.
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:
The CoC violations were in response to change requests.
The removal was likely justifiable soley on the basis of slow turn-around times for these change requests, without the vague CoC accusation.
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.
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.
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.
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).