Then there is no reason to refuse scalaz into the community build anymore.
Any project with stars lower than 500 should be excluded for ROI:)
ROI for the community build has nothing to do with github stars. I suspect the correlation efficient to be about 0.
R: Likelihood the project will find bugs / regressions in the compiler that other projects do not.
I: The time / energy it takes to maintain the project in the community build
Github
stars do not correlate with either of the above. For every reason I can imagine that a project’s popularity might correlate with one of the above, I can think of a counterexample of how it could go the other way.
Some
projects have very trivial investment to include in the build but might
not have huge return. Others might have large return but are a bit harder to keep in the build.
Two similar projects might have similar returns, while one of them is much lower cost to keep in the build. In such a case, the more difficult one to keep should be dropped, regardless of ‘stars’.
Of course, popular open source projects are where one first looks for what to include, but that is merely the first pass.
This is not a popularity contest, and no community should be insulted by being left out nor boast about inclusion.
It
is my observation that some project communities have become emotionally invested in inclusion in the community build, assigning far, far more meaning to it than it deserves from a technical standpoint.
8 Likes
What with projects with >500 stars which are inactive or for some other reason incapable of upgrading to the latest Scala versions? What with unpopular projects which are however depended on by popular projects? All Scala dependencies of a project in the community build must also be part of the community build.