Continuing on the discussion here: scala/contributors - Gitter , I open this thread to discuss how we can improve newcomer community experience, both for learners and professionals. Here are some things I have thought about:
Making it easier to find the right forum for questions
Consolidate forums (perhaps we don’t need all these channels (on the other hand, people go where they like, and plurality is nice…))
Making more clear how to file bugs and the relation between the Scala 2 and Scala 3 code base and its governance, e.g. roles of Lightbend and Scala Center
Making it clear who-is-leading-what and different community and governance roles and designated persons etc.
For community volunteers, perhaps some kind of voluntary who-is-who page – as a newcomer you see all these recurring names but you don’t have a clue of who this person is and what role they have and what their interests in Scala are.
I guess you at Scala Center are probably already discussing all this, but I think it might be good to open up for ideas from the community on how the on-boardning experience can be made more smooth, hence this thread.
I’m on-boarding 200+ CSE students each year that take my beginner programming course using Scala at Lund University, and for my students these issues are also really important:
How to make it easier to install Scala on your path in terminal on all major platforms (e.g. a runner for Scala 3 is lost since Scala 2) (Approx. distrib. of studens’ boxes when they arrive_ Windows 80%, Macos 17%. Ubuntu 3%, later they all get going on Ubuntu, either as VM or Dualboot, I suspect WSL will be more and more used.)
How to get going with the tools (esp. vscode / vscodium) without too many clicks and too difficult to understand lingo geared towards professionals. coursier is cool but I still find it somewhat lacking in functionality (where is the runner? how to switch between Scala versions in runner? etc) and the https://get-coursier.io/ pages assumes a lot of knowledge and is geared towards professionals rather than learners.
Install packages for all major platforms (for instance, my university sysadmins want .deb packages for Scala 3. We should not underestimate the install convenience needed for people with “managed” computers that try to convince an IT department to install stuff.)
These are just examples of stuff that could be important for on-boardning and newcomer community experience. Perhaps this thread can provide helpful input to Scala Center and Lightbend for later triage – if you all want to chip in with your thoughts!
Thanks to you all for a great community of a growing language
then scalaVersion can be adjusted easily within build.sbt, and all of IDE tooling is there to guide the beginner where in particular control+click code navigation is important.
Regarding runners I hope scala-runners would become standard so we can
From software developer’s perspective, arguably there is Unix-like platform convergence at this point since Windows WSL works fine, and is gaining even X11 support. After successfully enabling WSL with
Yeah, WSL is really great for convergence! But I guess there will always be a big number of devs who’ll need/want native Windows things, and we don’t want to loose that user base…
Or even just double-click on an .exe or .msi and it will get you scala+scalac on your path and providing pre-ticked tick-boxes for installing extra tools such as vscode with metals. And similar with brew or even a signed .dmg for MacOS.
It’s good to see more discussion around this. There is some overlap here with a recent proposal that we made via the Scala Center Advisory Board you may want to check out.
While most of the replies on this thread appear to be for newcomers to Scala itself, my suggestion has to do with managing the expectations of those already familiar with Scala.
There is a huge corpus of existing Scala 2 code especially within Enterprise IT departments. With the release of Scala 3, this huge corpus of code is now more rapidly gaining technical debt. For those of us having to maintain, update, and upgrade said Scala 2 codebases, being able to quickly drop in and evaluate where Scala 3’s current releases are which then facilitates our making decisions to begin sooner (rather than later) to explore the conversion and transition to Scala 3.
As such, it would be very helpful if upon each release candidate, a note was added about that specific release’s anticipated timetable. The questions I can imagine being asked by a said explorer are:
When was this release dropped?
If there are no showstoppers, when would the release expect to be generally available?
If a showstopper is found, does the new release candidate restart the +6 week clock?
How long after general release should one expect to wait for +90% of third party libraries to become available?
It might work more optimally if within the RCx notes, there was a link to an elaboration of the abstract answers to the 4 questions, and provide only concrete answers for questions 1 and 2.
Again, the purpose is to attract the already existing Scala 2 developers to begin exploring their conversions and transitions to Scala 3 as early as possible. The attraction is increased by anticipating and answering their timing questions as early and as clearly as possible. Until timing is clear, what is resolved in the release candidate implicitly remains a lower priority.
Improving and standardizing the structuring of the information in the release announcement even further, inline with what you suggest seems good. It is difficult though to estimate third party library migration paths, and that is really up to the library communities to communicate.
However, the situation of version compatibility is significantly improved with Scala 3 and the new Tasty technology so we should be better off from now!
But I’m not sure if this new improved compatibility situation is known outside the core of the community and it might also be a good idea to explain this in each release announcement.
I completely agree that the future of Scala depends on getting Scala 2 onboard to Scala 3 and also newcomers to start using Scala 3. A predicable release schedule and a release announcement scheme friendly to both newcomers and oldtimers is important, but needs work and feedback to continuously tweak to the better.
