7 ms·

I discussed this with isaacs in one of the nodeup episodes and we concluded that a pagerank implementation for authors and projects that reads in the npm stars

I discussed this with isaacs in one of the nodeup episodes and we concluded that a pagerank implementation for authors and projects that reads in the npm stars and dependency graph might work. It would also be useful to consider the github watchers, elapsed time since the last update, and the presence and status of tests, perhaps by ingesting data from travis-ci. Edit: turns out what I have in mind nearly already exists at http://eirikb.github.com/nipster http://eirikb.github.com/nipster

malandrew 15y ago
That's basically what I had in mind too -> edgerank for libraries. I reckon you'd need to have some sort of decay function that is relative to the amount of activity in that problem domain. In inactive problem domains (such as linting, which these days sees few commits and has almost no competition), you wouldn't need as strong a decay coefficient. Lack of activity suggests a solved problem or something that is no longer a problem. Highly active areas such as asset management (ender.js, browserify, require.js, etc.) you'd probably need some sort of coefficient for that problem domain. Tagging could be used to strictly or loosely assign packages to a problem domain. Acceleration is another issue worth considering. How quickly is a project being adopted among those that matter. Anyways, it's not a trivial problem to solve by any means once you get around to measuring social aspects surrounding a module, but it certainly is a step in the right direction. It's also a problem whose solution can be continually refined. TBH, I reckon that any refined system is going to look increasingly like a financial mark where certain behaviors are analogous to actions like put and call options. It'd be awesome to have a smidgen of transparency into private repositories in the form of aggregated gripping of the require() statements in active private projects. You could go even farther and look at the number of method invocations of a particular library. It would be cool to be able to view such data in the same way Google Trends works. For example, it'd be interesting to compare optimist, nopt, commander and nomnom. (going to stop now because I'm just rambling now. hehe)
- dkubb 15y ago
  Another idea I haven't seen mentioned is having a project building properly via travis-ci.org or some other CI system shows that the project is actively maintained and passing an automated build. Perhaps other metrics like code coverage could be used as well.

malandrew 15y ago

That's basically what I had in mind too -> edgerank for libraries. I reckon you'd need to have some sort of decay function that is relative to the amount of activity in that problem domain. In inactive problem domains (such as linting, which these days sees few commits and has almost no competition), you wouldn't need as strong a decay coefficient. Lack of activity suggests a solved problem or something that is no longer a problem. Highly active areas such as asset management (ender.js, browserify, require.js, etc.) you'd probably need some sort of coefficient for that problem domain. Tagging could be used to strictly or loosely assign packages to a problem domain. Acceleration is another issue worth considering. How quickly is a project being adopted among those that matter. Anyways, it's not a trivial problem to solve by any means once you get around to measuring social aspects surrounding a module, but it certainly is a step in the right direction. It's also a problem whose solution can be continually refined. TBH, I reckon that any refined system is going to look increasingly like a financial mark where certain behaviors are analogous to actions like put and call options. It'd be awesome to have a smidgen of transparency into private repositories in the form of aggregated gripping of the require() statements in active private projects. You could go even farther and look at the number of method invocations of a particular library. It would be cool to be able to view such data in the same way Google Trends works. For example, it'd be interesting to compare optimist, nopt, commander and nomnom. (going to stop now because I'm just rambling now. hehe)

dkubb 15y ago
Another idea I haven't seen mentioned is having a project building properly via travis-ci.org or some other CI system shows that the project is actively maintained and passing an automated build. Perhaps other metrics like code coverage could be used as well.