When evaluating a library on Github or similar, I usually look at
the following:
1. are there many open issues? How old are they?
2. are there recent commits?
3. is there a reasonable README file with examples etc?
4. are there unit tests (when applicable?)
While these are imperfect proxies for the quality/maturity of the
library, they can be used to form a reasonable first impression
before investing more time.
Best,
Tamas
On Tue, Jul 14 2015, Dmitry Vyal <dmitryv...@gmail.com> wrote:
I'm a newcomer as OP. And the most problematic to me is not a
huge number of packages but the need to manually evaluate
numerous alternatives while searching for desired
functionality. Some kind of quality or popularity rating would
simplify things tremendously. Or maybe some standard criteria
for production-ready packages could be established and packages
meet it should be clearly marked as such.
There are communities developing thousands of interrelated
packages (like drupal.org) which manage to tackle the issue
using variation of techniques I mentioned.
--Dmitry
On 12.07.2015 04:09, John Myles White wrote:
I think most of have the opposite desire: we're trying to move
more functionality out of the core language and into packages.
-- John
