back-link: https://github.com/scala/community-builds/issues/896
Exactly. If some person or community merits exclusion we need transparency about the reasons for that censure (and this is censure, not censorship).
Nobody is obliged to give a jerk a platform, no matter how productive their individual contributions may appear. Scalaz doesn’t seem to be hurting after cleaning up their house, so it’s a good example of the principle that “no person is irreplaceable”.
My biggest issue with this thread is that, while the OP asked for the transparency @adriaanm owes the community, and while there has been plenty of guessing from other people, there’s been nothing specific from @adriaanm .
OK, maybe they are a “small island in the dependency graph”, that’s fine, if a threshold is set and there aren’t any smaller projects.
If they’ve been behaving badly, that’s fine, be specific about what they did, and what they’d need to do to be reinstated.
it would be unlikely that we won’t have already caught the issue thanks to the remaining projects
Surely that means that excluding scalaz projects will not ease maintenance significantly
“One-time poster” here. Created an account here just to express my “WTF”.
Thank you for that comment, I believe it pretty well puts words on my own thought.
Well, this thread is a great little sample of what I meant by the painful social aspects of maintaining this part of the community build. Take all the public name calling, gross exaggerations and insinuations in this thread, and now imagine a private version as a constant stream of little paper cuts.
Supposedly, I’m petty, full of vengeance and a censoring despot. Actually, I’m just saying: enough is enough. If you want to be part of the community (build), act like it.
I think I am the only person to use the word petty. If you read what I wrote again you will see I didn’t call you petty.
It would be great if you address the valid points raised regarding the original reason for why they were removed, ‘coc incompatibility’ as well as the valid points raised about the subsequent reason you gave ‘not Pulling their technical weight’.
If you don’t want to address these points it’s fine to just say that and say we came to a unilateral decision that’s the way it is. It’s not how you folks have professed to want to run the community but it’s a valid approach.
Are you looking in the right place, Adriaan?
John has very politely and respectfully asked for your consideration: Add ZIO & Scalaz to community builds · Issue #896 · scala/community-build · GitHub
You are replying to random people in this thread. I realize it’s difficult to be flooded with unwelcome messages like this, but may I recommend taking a step back and refocusing on the message from the actual community contributor behind one of the projects that was removed. Thank you.
Actually, I’m just saying: enough is enough. If you want to be part of the community (build), act like it.
This issue was closed in favor of discussing it here. Clearly there is intent to be a part of the community build. Our own Kenji contributes to the community build, as well as to scala and scalaz. Our own @hrhino contributes to both scala and scalaz. Alex has logged more bugs in Dotty than anyone else. John has done incredible things for hundreds of Scala users - we don’t even need to quantify it here.
The bar keeps getting higher because you continually set it out of reach.
Well, this thread is a great little sample of what I meant by the painful social aspects of maintaining this part of the community build. Take all the public name calling, gross exaggerations and insinuations in this thread, and now imagine a private version as a constant stream of little paper cuts.
You’ve just gone out of your way to do work that excluded multiple projects from the community unprovoked. It has been months since you had any negative interactions with anyone active in Scalaz or Zio. You wielded the CoC in bad faith to eject entire projects from being considered a part of the community. You and Seth have done this in the past, and been chastised for it. There is no way to spin this as historical trauma.
Have those people asked you to speak for them? I have not negatively singled out individuals, and I won’t start now, but I have nothing but respect and admiration for Harrison and Yoshida-san.
I agree with this actually and there is no need for me to pollute this thread further. I think engagement between the community managers and the leaders of the projects that where removed is the least that should happen.
Yes, they have. Feel free to verify this information, and then answer any of the points I have made.
I think I would know when people are calling me names better than you. Have you looked in all the places I get called out gratuitously?
@adriaanm, what concrete actions would ZIO need to take to be added back to the community build?
I don’t doubt that at all. Which is why I mentioned that you must be getting a lot of unwelcome messages. My only point was to try to refocus this on the GitHub issue I linked, where a productive discussion can at least have a chance of happening, instead of in this thread, where it very likely won’t.
Unless I’m grossly misunderstanding the CoC, part of the reason it exists is to prevent maintainers from abuse, as much as it is to protect contributors from abuse from maintainers.
@adriaanm, you claim that there’s been a stream of abuse directed your way, and the community seems unaware of this.
As far as I’m aware, there isn’t any expectation of privacy when communicating with a maintainer in the course of their duties. Surface the abuse so the community can have your back. The Scalaz folks have shown themselves willing to do so in the past.
I won’t surface private interactions, regardless of expectations of privacy. I also don’t expect this to be resolved in public. Our trust and confidence has repeatedly been damaged, and you’re not just going to get it back through lip service.
Then provide a path to recovery, please. If you find you cannot fulfill your duties as a community leader without engaging in passive aggressive or unethical behavior like this, then step away and let someone else take over.
I work on a 9 year old project with 100k lines of scalaz code. It would be great if Scala continued to be tested against scalaz. We are trying to avoid writing Scala in the future, so I’m not very confident that we’ll upgrade Scala versions, but I would value Scala’s commitment to backwards compatibility.
While normally laudable, discretion in the face of abuse is not a virtue. Particularly because in this case, there isn’t privacy to protect. Even more so because, if they’re willing to abuse in a situation with no expectation of privacy, they’re likely behaving even worse in other contexts with stronger privacy guarantees.
At this point, because of the way the initial PR was handled, it kind of has to be revolved publicly.