Here is technical discussion. I can not see useful suggestions to make maintenance more effective.
I can see only exhaustion.
I think that they are wise enough not to do so.
But it is a matter of faith, so let us not argue.
@adriaanm, I can’t speak for anyone else, but the reason I’m here is because this looked like an off-the-cuff, unilateral decision, justified by unspecified accusations of CoC violations, made by a maintainer who’s also a SIP Committee Member.
Autocratic behavior doesn’t tend to be compartmentalized, so it was a bit more worrisome than just a maintainer deciding their time would be better spent elsewhere.
As it happens, you had solid reasons for dropping these projects, but playing your cards so close to the vest doesn’t help what this looks like to those of us without access to this context.
So, at least for me, by association this experience erodes my confidence in the fairness and transparency of the SIP Committee.
12 Likes
That is not what you’re after, and it’s abundantly clear from your history. 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, all based on one commit and my comments here — all of which I stand by.
3 Likes
This has nothing to do with the SIP process.
1 Like
First timer there, too. Not a scalaz user.
I know there’s a lot of backstory that 99% of us are not privy to. I don’t really care to know but things like this tend to drag the rest of us into some strange conversation that we couldn’t possibly comprehend.
I don’t particularly care if these projects are included in the community build. Removing them for incompatibility of the CoC seems fair, although after further explanation it seems to be a violation more than incompatibility. In either case I’d want the maintainers to be clearly notified as to the cause. That obviously wasn’t done and the subsequent explanations fall flat in my eyes. Especially after reading the Scala CoC which I’ve actually never bothered to read until now.
In the Scala community we strive to go the extra step to look out for each other.
A heads-up about the removal would have been a fair extra step.
If someone takes issue with something you said or did, resist the urge to be defensive
Clearly Emily took issue with the removal and I didn’t see anything provocative or dubious about her initial post. I think she deserved a reply more in line with the CoC. Especially given that
Moderators are held to a higher standard than other community members.
If the CoC is the reason for the removal then it should also dictate the manner in which the removal and subsequent conversation are handled. My 2 cents.
11 Likes
That is a frustratingly obtuse reply to a very well articulated post.
I suggest that you take what was said with sincerity. This is a user expressing concern from the way things were handled here. Taking that concern seriously and perhaps thinking about constructive ways to improve is a better response. Dismissing his concern all together will exasperate the concern.
4 Likes
You’ve edited it out now, but just a few hours ago you were suggesting I have mental health issues
Because it’s not the place to discuss this. You can’t communicate with us because of some trauma that occurred in the past, and nothing has happened for close to half a year now, but you immediately break down as soon as we press you for an answer. You can’t even de-escalate now! Just let it go. This is not a personal crusade. We haven’t spoken since like, what… November?
1 Like
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.
1 Like
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.
3 Likes
Your responses explain exactly why they don’t want to work with the scalaz team anymore.
6 Likes
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.
3 Likes
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?
6 Likes
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).
7 Likes
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.
2 Likes
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).
4 Likes
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.
3 Likes
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.
5 Likes
Many devs are coming out of the woodwork for the first time here in this thread to show disagreement with how this was handled.
If that is not alarming in the least nothing will be.
9 Likes
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.
5 Likes
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.
2 Likes