Awesome-go: Show GitHub star count next to project link.

[lishuhao]

It's great, but it will be nice display star counts in the list, sorry for my poor english

[deankarn]

Stars are often not indicative of quality as people use them for bookmarking

[kirillDanshin]

I already think about it and I think it is a bad idea.
we all know about iris a their almost-one-day 5000-star increment, and we all know that nobody will rebase their PRs every hour to solve merge issues.

[dmitshur]

and we all know that nobody will rebase their PRs every hour to solve merge issues.

Doing something like this would have to be done via an API, there's no way to manage this manually.

Stars are often not indicative of quality

How about the number of importers (other packages that import a given package)? It'd be harder to do, but more meaningful than stars, maybe.

godoc.org has an API that exposes its knowledge of importers. E.g., the github.com/google/go-github/github package is currently imported by 359 packages.

[nouney]

With a simple python script and go-search, it's possible to do something like that.

[deankarn]

Unless I'm mistaken the number of importers is not guaranteed either as the numbers will not include private importers.

[kirillDanshin]

@joeybloggs yep, that's right.
exemplī grātiā, I use dlog in about hundred packages but https://godoc.org/github.com/kirillDanshin/dlog?importers shows only one.

[deankarn]

I don't mean to sound like a pessimist, and all of the ideas above are good, however this is a discussion has been had before not only here but in many similar sites without a concrete answer/solution

• stars are too arbitrary due to people using for bookmarking
• importers only shows public and not private
• latest activity isn't reliable as the code may be stable
• the list goes on....

I would personally not like a unit of measurement on any package/link as it can incorrectly lead people to the conclusion that more(or less depending on metric) is better.

I would say that usually each package has something unique about it and it is up to the developer to determine which is best for his/her situation.

I would hate to see some great packages overlooked, just because it didn't have a bunch of stars.

[AlekSi]

We can use @buger's expirience from building https://ossmetrics.com.

[buger]

Thank you for mentioning.

There is no, and never be a clear metric on how to measure project success. There are packages which have 30 stars, but thousands of repositories depend on them, and there are projects with thousands of stars which are abandoned.

I indeed trying to this figured in my https://ossmetrics.com project. There is no way to tell how professional project is, and if it is ready for use in production, but there are things we can measure. For example active community, or quality of support.

I for sure thought about adding "badges" for repositories to show number of active collaborators, let me know if you interested in it.

Thanks!

[mrichman]

There's a way to get download count here: https://help.github.com/articles/getting-the-download-count-for-your-releases/

[deankarn]

Unless I'm missing something @mrichman this only applies to the compressed source code downloads and any other binaries added to the release and not the actual code's files.

And since go get wraps git clone these counts won't be incremented.

[mrichman]

How about the number of clones? https://github.com///graphs/traffic, though that data might only be visible to the repo owner

[deankarn]

Its's not a bad idea, however, with all the cloning from CI testing makes this unreliable as well, even if we could get the data. Also just because it's cloned a bunch does not make a project good or bad.

[kirillDanshin]

@joeybloggs about CI clones: numOfClones * 2 / 3.14? :))