Good work!
Glad to hear that Scaladex is better behind the scenes! The search capability and UI could also use a bit of improvement in my opinion…maybe the reduced technical debt will allow that at some point?
Awesome Scala is awesome, but it is a bit weird that you’re dropped directly into “Asynchronous, Concurrent, and Distributed Programming”. I mean…that stuff is awesome, of course. But it would be better if the landing page was in some sense the most awesome-of-the-awesome (by popularity) or picked out some great libraries at random, or something like that. Unless you have data to indicate that async is the most in-demand thing, this seems like alphabetization driving a pretty important first impression. Like, personally, I would think having sbt, mill, better-files, spark, etc., on the landing page would make more sense.
The Inclusive Language Guide is a good idea–a lot of these things are not necessarily obvious and guidelines can help. But there are two parts of the document that seem really weak.
First, blacklist/whitelist ends with an admission that there is no accepted solution and a really clumsy suggestion: “excludelist”–ugh, who wants to say (or type, or read) that? I think it would have been better just to raise the problem and leave it to the community to find another comfortable way to talk about it if there isn’t already a good standard. I am almost positive that excludelist isn’t going to be it, given other possible alternatives (including two-word ones like “allow list” vs “deny list”, “accept list” vs “reject list”, and so on). The L-D-L thing is just physically clunky if you’re trying to say it.
Secondly, “sanity check” has a very different connotation from “confidence check”. An actual sanity check examines only the most ridiculous types of predicted wrongness, like “does this phone number have digits in it”. It might be good to switch from the idea of “let’s only catch the most patently absurd situations” to “let’s assess the degree to which we believe this is correct”, but if so it should be made really clear that you’re changing the approach not just the phrasing. As it is, the suggested correction is unhelpful because the meaning is too dramatically changed. “Feasibility check” is a better match for coding because it too suggests that you’re not being terribly careful here, but doesn’t cover all the same ground because “sanity check” can also be used for arguments (“let’s have a quick sanity check here–at 250C, the water isn’t going to be liquid, so the thermometer must be broken”) where you’re not trying to accomplish anything and therefore feasibility isn’t relevant. “Integrity check” for user input data that isn’t necessarily going to be used for something is another option.
Finally, I do wonder whether the “inclusive language” guidelines are driven by data about what people in practice find non-inclusive? It seems like there ought to be more to say about things like avoiding idiomatic expressions and cultural references (to be more inclusive of people with less mastery of English or of different cultures), using technical terminology when and only when critical for understanding (to be more inclusive of people with different technical backgrounds), and so on. Once upon a time advice of this sort was common, and anecdotally I have in the past heard complaints about these things being a barrier to entry when not followed…but maybe it’s so ingrained now that we don’t need to repeat it?