-
Notifications
You must be signed in to change notification settings - Fork 25
Description
With 900+ packages, there are many cases of packages that do almost but not quite the same thing. For instance, try picking an autocomplete/typeahead package. Note how their description doesn't mention some critical features (search by multiple fields, trigger symbol or not etc.)
How should the new meteor user (not contributor) make an informed choice? Remember that 90%+ of users don't contribute, and won't ever bother to file GitHub issues. This is a rule of thumb that applies to most communities, and something I've personally experience - just look at the atmosphere issues I've opened concerning abandoned or obsoleted package - mine was the only issue notifying the author about the problem, in the many months since they published the package.
Creating issues on the GitHub fails for multiple reasons:
- The package may no longer exist (example I found just today)
- The author may no longer have time or interest in maintaining it
- If a package is no longer maintained, obsoleted by another, and just clutters Atmosphere, it should be removed. Some authors may feel reluctant to remove their packages when they become obsoleted, out of attachment to their work.
- Until the author gets a chance to update their package, users will continue wasting time with it.
The latter is my case today while trying to pick an autocompletion package. All the information I gathered will NOT be accessible on Atmosphere unless and until the authors take the time to accept my pull requests and republish the packages. And remember, that is a fortunate situation, because I'm one of the <10% who contribute.
Another argument: the best package repository for any language is by far CPAN for Perl. And they support comments, which have been extremely useful in helping users select the right package.