@heathermiller said the “Scala Platform” and Process was up for debate and could be thrown out.
This is one such attempt 
I am glad to see all the energy surrounding the Scala Platform and Scala Platform process. I see a lot of good and useful ideas in what has been proposed. I do share in some of its criticism and may have some of my own. It is a sizable document. Rather than getting pulled into a large discussion of its many points, potential pitfalls, and how they might or might not be changed, I seek to propose what I hope is a more constructive direction. In reading through the questions that have been asked, the issues raised, and trying to understand it myself, I come to the following underlying opinion that I believe addressing has the power to address many issues:
The Scala Platform and Scala Platform Process proposal is too big. That is, it is trying to do too much, under one name, at one time, with too much planning.
It is very understandable how that happened, such planning is natural under many processes. I implore that the approach is not the right one in this case because it runs counter to its goal of “[g]row the Scala community and help its expansion,” because of the in risks dividing the ecosystem and alienating current contributors and authors. I don’t discount that the individuals involved in writing the current artifacts may have incredible foresight and the current documents may outline exactly where the Scala community ends up. Remember though, the best laid plans […] often go awry. I wish to encourage a process of broader community engagement is an alternative way work towards the goals.
The good news is there is a vibrant community that can be engaged in helping to meet the goals stated by the Platform and Process proposals. I propose treating these initiatives as collaborative efforts just as the open source projects within the Scala Community they seek to foster. While the approach may seem more gradual approach at achieving the original vision, it may actually yield results faster and yield better results through higher engagement.
I have tried to strike a balance between communicating how smaller initiatives can lead toward the expected vision and not over-planning by fleshing out all the relevant ideas I can think and how I predict they may progress. I have outlined three some concrete examples of approachable ways to get started which I hope demonstrates how the Scala Platform and Scala Platform Process can be split up (modularized) with multiple, iterative initiatives that can lead towards the desired goals.
These are summarily,
- Identify ecosystem Best Practices (or Desired Norms)
- Establish better building infrastructure for Scala [in the cloud]
- Demonstrate the value of community processes
For each of these was taken from some part of the SP[P] discussion. For each I identified of the problem it hopes to address, an initiative, implementation details, related example outside of the Scala community, how the initiative may be a jumping-off point for future efforts, and optionally additional rationale behind the decision as proposed.
Please enjoy, comment, and let me know what you think.
Identify ecosystem Best Practices, or Desired Norms
###Problem
A diverse ecosystem with diverse practices, nomenclature, and conventions increases the mental load on users. This creates barriers to entry, adoption, and contribution.
###Initiative
Scala Standard Practices
###Implementation
This should not be the bucket list of everything that is desired up-front for “Platform modules.” Start with low-hanging fruit: relatively non-controversial things that have a big impact on consistency. Some of these may seem obvious, but there is value in codifying the norms so a user can easily navigate the ecosystem with fewer surprises. Likely, many popular projects already follow these. If the projects do not, try to understand why they do not. Perhaps, it is an education issue. Perhaps, the initially identified norm was flawed and needs to be revisited. Once confident about the general usefulness of a practice, engage (submit PRs, discuss, sell the benefits, help, etc.) with projects that do not follow it to see if you can bring them on board. Ultimately these may change over time, but they should not be forced.
Possible Examples (There are many more):
- Use SemVersioning
- List on Scaladex
###Related contemporary examples
- In the Node.js world, an expectation for SemVersioning is such a norm to the extent it is even built into the tooling. It is easy to specify a dependency on the latest compatible version of a library. If a library were to not follow SemVersioning users would see breaks and it would stand out (in a bad way) for not following the conventions.
- In the modern .NET world, if your library does not have a NuGet (package manager) package, it might as well not exist.
###Possible future initiatives
The above is about establishing a minimal baseline of norms. In the process perhaps other practices will be thought of that for whatever reasons were not acceptable as general norms (at least at the present time), but are believed by passionate individuals to be important for the future of the community or are strongly desired by a certain subset of users.
There is not a good prescription for getting these more established. I would argue it would be a Bad Thing if such a prescription were possible, because the reason it cannot be prescribed is that there is a healthy community. If it is truly a good idea there are plenty of ways to help spread the idea in the community and hope to gain greater participation. Having success with the above in establishing norms, will give more credibility to efforts towards adoption of more controversial norms.
Remember that many problems are complex with multiple contributing factors and may take multiple initiatives to fully address. Also, remember to consider if the originally stated problem is the actual problem, or a symptom of another underlying issue. To illustrate here is an example of one possible progression related to the above initiative:
Problem: User group X wants to choose only libraries that have a build available for the current and previous Scala release.
Sub-problem: Binary incompatibility between Scala versions is not going to be eliminated in the immediate term and users want to know a library provides builds for their desired Scala version(s)
Initiative: Scala GitHub Badges
Implementation: Establish GitHub badges (like build status badges, gitter badge, etc) tied to Scaladex (or suitable other system) that displays information on compatible library/Scala versions. Submit pull requests to existing libraries adding these to the README.md and/or website, as applicable.
Rationale: Unless a project is simply against badges in general, this should hopefully be welcome assistance to the project. A consistent interface for users to see where a library is supported, or what version of a library is supported on a platform, is beneficial to everyone. Done correctly, displaying the badges should not require ongoing effort from the maintainer. Users get the benefit of easily seeing where they can use a library. Contributors can see when a library is not supporting a version and can get involved.
In addition to the above, the aggregate side (Scaladex) has valuable information for User group X, or other user groups looking for a specific availability profile. There they can see what libraries are likely to meet their desired profile. If a library they need does not meet their profile, or they want a stronger guarantee of continuing to meet that profile, they can engage with the library maintainer to see if it could could be a possibility.
This is likely not the end of the story for this problem, but I am already one “hop” into the hypothetical so I won’t publicly speculate where things could lead from there.
Establish better building infrastructure for Scala [in the cloud]
###Problem
Robust builds of Scala code cannot always be freely built on the COTS CI platforms commonly utilized by projects on GitHub. This puts Scala projects at a disadvantage and complicates life for authors and maintainers of Scala libraries
Initiative: Scala Center’s Drone Scala builds
###Implementation
Easy enrollment of Scala libraries, hosted on GitHub, into the Drone instance’s build queue. This is not far removed from what already has been proposed regarding build so I do not elaborate.
One deviation from the language in the Process document is that this build process and configuration, in so much as is possible should be open and community-owned as well. This would allow the users to help with maintenance/features as well as allowing instances outside of EPFL if the need arises.
###Rationale
If this is truly a problem, it is in the community’s best interest to solve it generally and not just for the “Platform Modules.” In so far as computational resources allow, there should be minimal barrier to making use of this resource.
###Possible future initiatives
When computational resources become an issue, this would be a strong indicator of success for the initiative. If that happens was successful and it can be evaluated how to either grow it to maintain support or restrict it to stay tractable.
###Related contemporary examples:
- AppVeyor
- Travis CI
Demonstrate the value of community processes
I know there are other factors surrounding the following problem as well, but I find this telling slightly amusing.
###Problem
Problem: In recent history, the Scala Standard Library has not been developed at the same pace as the Scala Compiler nor the rest of the Scala ecosystem.
Solution: Modularize the standard library to make hacking on it easier.
New Problem: The Scala Standard Library is being modularize (split). The core library will be part of every distribution and likely maintained as currently. What do we do with everything else that had been part of the standard library?
Solution: Turn it over to the community.
New Problem: Okay… but, how?
###Initiative
Scala Community Governance with C4
###Implementation
Most of the ingredient have already been identified. Actual implementation depends on people that, to my knowledge are not yet identified.
Ingredients:
- Code liberated from the Scala Standard Library
- The Scala Code of Conduct
- The MPLv2 License
- The Collective Code Construction Contract (C4)
###Rationale
There is no denying this is an experiment. I do not think there is enough science to know definitively the best way to implement this. Should one project be started early to work the kinks out of the process? Should they all be started at once? Are there conscious differences that you want to make between them initially to see what works best? There are a lot of lessons to be learned here, I think.
Related contemporary examples
- ZeroMQ - Thriving open source community and testbed for the C4
- .NET Core, or however one refers to the new open source implementation of the .NET Platform by Microsoft. Relevant both as a new open source community and because of the modularization effort made to the platform
- Serilog - Open source .NET logging library that relatively recently (last 2 years) underwent into “core” and “community” modules.
###Possible future initiatives
The big sell is that, if this goes well, there is a much stronger case for getting existing projects in the Scala ecosystem to adopt new practices hoping to share in the success.