A markdown based README can be parsed to find headers corresponding to the man pages spec or else if there is no pattern match, a set of basic rules.
Reaching version 1.0 for node modules represents a significant milestone in stability.
When someone runs npm star <module-name> they are making a public statement about their appreciation for it.
When someone stars a github repo they are making a public statement about their interest in it.
Agreed, any of these metrics aren't valuable alone, but hopefully the list will give a good snapshot into the value of a module.
Any thoughts on implementation?
@SaraJo implementation is easy, making sure we are implementing the right thing is the hard part ;)
It seems like there should be some metric involving age of open pull requests. If the pull requests are not being dealt with in a timely fashion (pulled or denied) then it shows a stale project. Perhaps average number of day age of pull requests?
It frustrates me greatly when there are open pull requests solving critical bugs that are being ignored.
@wshaver +1
+1 this will help a lot
I'd love to see tests / test coverage as part of quality, however best expressed?
@clintandrewhall added
+1 This would be excellent for any package management
Great list! I think this can be broken down into a few categories: health, popularity, and quality. They can be orthogonal to one another.
Health: # of active contributors, days since last release, days since last commit, # of open issues, avg response time to bugs.
Popularity: # of npm/github stars, frequency of downloads, # of dependent modules.
Quality: Performance (relative to similar libraries), has tests, has/passes CI, has documentation.