Require C4 process for libraries?

[jvican]

@odersky

I think, generally we need to give much more power to contributors of the platform, and limit the power of the review committee. Otherwise, why would anybody contribute to the platform? What’s the incentive? The way I see it, the oversee committee is a good first step. But it should largely step aside and let the platform be defined by the people of commit to it and maintain it, once there is a group of such people.

The SPP Committee only decides the library to be included in the Scala Platform and “incubates” it. That’s all its control over modules. If that process is successful, it’s immediately released with the next Platform version. Details here.

@Blaisorblade

In fact, would the platform ever contain 2 HTTP libraries? If yes, don’t I have to pick again? If no, how would I migrate?

No, the idea is that one need, one module. For instance, let’s hypothesize and say that the SPP Committee decides that it needs test frameworks, one for property-checking and the other one for unit testing. In this case, both scalacheck and scalatest would be eligible because they solve different needs.

I think that once a module falls unmaintained, the process would look like this:

1. The SPP Committee analyzes the situation. Why has the module fell unmaintained? Was it used?
   1.1. If it was not used, the SPP Committee can decide not to replace it.
   1.2. If it is used, the SPP Committee calls for an alternative (and a member that submits a SPP proposal).
2. If there are several alternatives, the Committee starts the review process as usual.
3. If there is only one alternative, it automatically incubates it to be released as soon as possible.

This process would be executed before removing the unmaintained module from the Platform.

@Ichoran

I would prefer if C4 were made recommended rather than optional. That way if someone doesn’t feel like being a guinea pig, they don’t have to adopt it.

I’m starting to see this as a viable solution. We could just recommend it, and I like your idea of enforcing it as a “rescue mechanism” if a library falls unmaintained. However, I want to highlight that C4 would be more useful preventing these issues if it was adopted from the beginning.

These are the reasons why we decided that C4 was a good idea:

1. It prevents uncomfortable situations with bad actors. Our community has already had issues with this in the past. Prevention is better than cure.
2. It gives reasonable defaults to lead a project and engage contributors. In fact, it gives contributors some guarantees that make it more likely that they continue their contributions and even become maintainers. Library authors will not stay forever, they will come and go, so having a mechanism to elect them is important.
3. It makes contributions easy for outsiders. Imagine a company that wants a quick way of assigning a developer to work on a project (or maintain it) because they depend on it in production. If there are concrete rules to do this, following the process is straightforward. Maintainers will need a hand… sooner or after, to take care of their projects. We cannot completely rely on them because their absence and the lack of motivation in contributors will lead our projects to fall unmaintained.

Having said this, if people still feel that C4 is an inconvenience to library authors (to be honest, I just see it as an advantage that makes my life easier) we can indeed recommend it and not require it. But I’m dubious if this will interfere with the end goals of the SP: creating communities around the Platform and helping Scala developers by providing a stable collection of modules.