Please curate this list

[kweber-tcc]

This seems to me to be a list of any Go library that is submitted. There are MANY libraries included with less than 100 stars and absolutely no documentation. (Examples: https://github.com/siddontang/go-log, https://github.com/white-pony/go-fann, https://github.com/daviddengcn/go-pr, https://github.com/e-dard/godist) Many libraries have no tests. Many are no even stable yet.

What is the point of a curated list that accepts anything submitted? How is this a list of awesome Go code? Why are you not even adhering to the quality standards set out in your own README?

Please remove the less-than-awesome libraries, so this is actually an awesome list.

[kamilsk]

good point (except less than 100 stars)

[avelino]

I find it relevant to this question to improve the quality of the list.

Star in Repository does not demonstrate the quality of the project, today we review the proposals asking for the following items:

• test (coverage should be >= 80%, tool to help cover.run. There's a packet we can't charge that item, example: Add webview library #1594)
• lint
• documentation
• read more: https://github.com/avelino/awesome-go/blob/master/CONTRIBUTING.md#quality-standards

I think it's important to ask for minimum X stars, my vote is for 42 stars ("The answer to the ultimate question of life, the universe and everything is 42")

What's your opinion? @cassiobotaro @felipeweb @crgimenes @shurcooL @dukex @matrixik @joeybloggs @kirillDanshin @appleboy @PotHix @campoy @ianlancetaylor

More reviews thread: https://twitter.com/avelino0/status/918520765028491265

[marioidival]

I do not like this measure by stars. Tests and documentation it's better to this...

[caarlos0]

Maybe having a good score on goreportcard as well?

[dmitshur]

I think it's important to ask for minimum X stars, my vote is for 42 stars ("The answer to the ultimate question of life, the universe and everything is 42")

What's your opinion?

Number of stars is a measure of how interesting a library is multiplied by how many people have seen it. If a good library is created and not yet shared everywhere, it won't have many stars. That doesn't mean it's not good, just that it hasn't been shared/seen by many people yet.

For example, https://github.com/golang/arch is an official Go repository that has 17 stars at this moment.

I don't think there should be a minimum star requirement, because stars are not a measure of quality, they're a measure of interest and exposure.

Also, not all Go packages are on GitHub.

[theckman]

It seems very contrived to correlate the quality of the package/software to the interest in it (stars). We've seen projects on GitHub get a lot of stars, very rapidly, when they hit HackerNews... even if that project isn't the best solution. I don't think a Public Relations explosion of a project, that's a week old should, be an indicator of its quality.

Maybe we could form as a small group of individuals in the community to help curate the content? We could use the Golang Slack group, in a public channel, to make the decisions and process transparent. I suppose we could also use GitHub pull requests to accomplish the same.

If we could start with some manual curation, we might be able to find patterns in the projects we've curated to try and make it more automated.

[schigh]

It's tricky. Sometimes a large number of stars is just a by-product of good social engineering (if it's on the front page of Hacker News, it has to be good, right?)

That said, there is definitely a critical mass somewhere that would clearly indicate that a package is not only popular, but also useful and relatively bug-free. I have no idea what that threshold might be (probably 500+ in my opinion).

But that leaves less-widely used packages written by lesser-known developers in a bit of a bind. I have seen some amazing packages with 10 or fewer stars that definitely deserve to be on your list.

I think at the very least, the following things must be included in order for a curator to even consider a package:

• Code coverage of 85% or better
• Goreportcard score of B+ or better, with tile at top of README
• Godoc reference tile at top of README
• Travis (or other CI) build passing for current release, with tile at top of README

I think you should also add all the tiles (coverage, goreportcard, godoc) as links beside every entry on your list.

This would be a lot of copypasta work, but I'd be glad to help with it ;)

[dmitshur]

Another factor to keep in mind is that by setting criteria for inclusion, we influence the kinds of things people are more likely to do. If we make it good things like having documentation, tests, no lint issues, etc., people can fix those.

If we make it a requirement of having minimum N stars, we'll be causing people going out of their way to seek out stars, likely by annoying others and spamming their repository everywhere. I don't want us to have that effect.

[matrixik]

I'm with @shurcooL we should require only things that can be directly affected by repo owners.

[cassiobotaro]

Stars are not a good metric. Maybe a proposal to change coverage when project is hard to test, but i'm really afraid about that.