For me github is awesome. Generaly 5-10 minutes of digging through the code is enough do decide whether you like it or not and if you like it you don't care so much about popularity, battle testing and other boring stuff. You just confident. Otherwise when code is bad no matter how many forks and watchers and dependents project has you are still not happy and looking for something else. Popularity is not a measure. I know few popular modules but it whould be probably better if they never been published.
it perpetuates modules that are created by people with more visibility > Such people centric approach when you know not only module but also a person who wrote it is awesome. Next time when new module comes in you just know what to expect, how it will be maintained... As a conclusion: I am happy with github, I think nipster <http://eirikb.github.com/nipster> is a right direction. The only thing I'd like to call community to is to* be responsible while pushing new module to the npm, be confident that it will add a value*. There is no need for some kind of approval process and so on, it's not bad if someone accidentally overrates it's module. Just a Will is enought. It's a question of culture and culture can be cultivated. On Tuesday, April 10, 2012 8:53:49 AM UTC+4, Nuno Job wrote: > > Hi guys, > > I've been thinking a lot about this topic and seen some interesting > websites created by the community to answer the question "what is the most > relevant module to perform task X" > > This is becoming more and more important as in the last episode of nodeup > (and in a recent blogpost) isaac reiterated this as something that needs > some love in node and that will probably change in the future. Im going to > share my opinions and then leave it up to the list to discuss. > > To me measuring quality of a module should exclude third party sites, > especially github. There are plenty of ways to social engineer it and it > perpetuates modules that are created by people with more visibility vs. > more often used ones. > > To me the measure of quality should rely exclusively on statistic from the > couchdb http access logs from npm. We could think of times a thing is npm > installed as pageview, and time it is installed per application (or module) > as unique views. We can also get aggregates of what modules are used more > often by other modules, and by applications. We can check for modules that > are more popular in a specific region, and even test if they are running on > production (eg downladed from nodejitsu.com) > > Scoring each weighted component like in tridf would normalize results. > PageRank is an absolute necessity but seems like a manual process to me. It > seems fair that people that have modules that are used by other people are > the people that could vote for this pagerank, which would contribute for te > final score of the module also in a weighted fashion so we could fine tune > the scoring > > This also seems to be quite dynamic and volatile in nature, so static site > would probably not offer an ideal quality index. > > Looking forward to everyones opinions, > > Sent from my iPhone > > -- Job Board: http://jobs.nodejs.org/ Posting guidelines: https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines You received this message because you are subscribed to the Google Groups "nodejs" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nodejs?hl=en?hl=en
