Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?
general heuristics for ranking package quality

Health

Has CI

Tests pass

Total number of breaking commits

Number of dependencies

Average age of issue

Frequency of issues fixed

Average response time of issues fixed to bugs filed

Last commit

Frequency of releases

Popularity

Number of dependent modules

Number of total downloads

Frequency of downloads

Frequency of commits

Number of contributors

Quality

Is well documented.

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.

Number of Major releases

Reaching version 1.0 for node modules represents a significant milestone in stability.

Number of npm stars

When someone runs npm star <module-name> they are making a public statement about their appreciation for it.

Number of github stars

When someone stars a github repo they are making a public statement about their interest in it.

@jeresig

This comment has been minimized.

Copy link

@jeresig jeresig commented Jan 21, 2013

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.

@SaraJo

This comment has been minimized.

Copy link

@SaraJo SaraJo commented Jan 21, 2013

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?

@heapwolf

This comment has been minimized.

Copy link
Owner Author

@heapwolf heapwolf commented Jan 21, 2013

@SaraJo implementation is easy, making sure we are implementing the right thing is the hard part ;)

@wshaver

This comment has been minimized.

Copy link

@wshaver wshaver commented Jan 21, 2013

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.

@heapwolf

This comment has been minimized.

Copy link
Owner Author

@heapwolf heapwolf commented Jan 21, 2013

@rajaraodv

This comment has been minimized.

Copy link

@rajaraodv rajaraodv commented Jan 21, 2013

+1 this will help a lot

@clintandrewhall

This comment has been minimized.

Copy link

@clintandrewhall clintandrewhall commented Jan 21, 2013

I'd love to see tests / test coverage as part of quality, however best expressed?

@heapwolf

This comment has been minimized.

Copy link
Owner Author

@heapwolf heapwolf commented Jan 21, 2013

@brucecoddington

This comment has been minimized.

Copy link

@brucecoddington brucecoddington commented Jan 22, 2013

+1 This would be excellent for any package management

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.