When should we consider a proposed library "good enough"?

[jvican]

Thanks for bringing up this interesting discussion @jducoeur.

@jducoeur

That’s a valid line of argument, but IMO is a lot more valid when it’s paired with, “and here’s a better alternative”. (Or even a concrete plan for somebody to build a better alternative.)

I cannot express how much I agree with this statement.

@jducoeur

If something could be significantly better, but that “better” doesn’t yet exist and the bird in hand is a considerable improvement over the existing APIs, is that “good enough”?

I think we should consider all the libraries that exist in the present and meet the most important criteria of a concrete problem domain. As I mentioned before, we need to turn our hopes/requirements into actions that help us improve what we have right now. There’s always room for improvement. My rule of thumb is to convert any suggestion into an actionable item that I (or others) can work on. This is what moves us forward.

@jducoeur

Is it better for the Platform to include the library (which we anticipate is likely to eventually be superceded by something more appropriate, but makes life better in the meantime), or leave it out (leaving the community pain point, and maybe inspiring somebody to actually write and contribute something better)?

Modules are not meant to be the same for years. They are meant to evolve over time, as the users’ requirements and use cases change. If a module is accepted into the Scala Platform, it means that for 10 Committee members that solution is the best among the current ones. But our job is not done yet, it’s just started! If we’re at home and think that a library could be improved, and we have some time, why don’t we do so? If we don’t have time, why don’t we open an issue and propose an improvement or draft a plan?

With this, I mean that the future of the modules is in the maintainers/contributors hands. Disagreements are settled with PRs and discussions. If there is a problem with a module or a feature is highly requested, someone can get it done. It’s not as in the case of the standard library, where things will not be fixed because of strict compatibility guarantees, unoptimized contributing experience and slow release periods. The case that you mention “likely to eventually be superceded” will not apply, we don’t need to supersede a library, we just need to evolve it.

To me, a proposed SP modules is eligible when it fits the official Scala Platform module definition:

A Platform module is a library of the Scala Platform. Platform modules should stress stability and usability alike, and enjoy widespread use in the Scala community. Modules should be of a nature that aids the goal of the Scala Platform and should have compatible licenses with the rest of the Platform modules.

As you see, stability, usability and widespread use are major features of SP modules. How do we measure them, though? The idea is to get data that backs up statements like “this library is stable”, “this library is widely used”. The better-files proposal is a good example of a proposal because it gives us objective data to assess the current status of the library. This methodology is not full-proof, but hopefully help us to be more productive and focused at the discussions.