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.

[deankarn]

stars != quality agreed

In my experience 99% of the time a project is hard to test it’s because of the way it’s composed and can be better refactored to support tests; having said that there are edge cases but those should be treated on a case by case basis IMO

[dvrkps]

Number of imports is also valid metrics for library type packages.

[kirillDanshin]

@dvrkps No, and will never be. You forgot about thousands of closed-source commercial projects.

[dvrkps]

@kirillDanshin yap, you are right. i forgot that :)

[avelino]

By the majority vote we see that star is not a good metric, closed the issue.

[PotHix]

Hi, folks. I have something to add to this one. Looks like this issue is not just related to the number of stars but to improve the curated list. Is the go-fann library (just one example) he mentioned according to our current standards? In case it's not, the issue is still valid.

@avelino ☝️

[dmitshur]

That library was added in 2014 directly into master without a PR, see 5bf6e08. At that time, the standard for inclusion was probably quite different.

If there are issues with individual libraries, they can be dealt with specifically.

[PotHix]

I don't think this argument invalidates the content of the issue. The issue asks to curate the list. In case it was valid in the past and it's not valid anymore, it should be removed. Isn't that the case?

Maybe this issue is too broad for that and we can split into multiple issues or get help for that, but the content is still valid.

I'm just saying that a good reason for closing would be: "We will work (or wait for PRs) to remove the libraries that are not awesome (according to our standards) anymore".

[dmitshur]

I didn't say the content of this issue is invalid, I just dug into the history of how that package was added and shared my findings.

Maybe this issue is too broad for that and we can split into multiple issues or get help for that, but the content is still valid.

I think that'd be more actionable.

[dadleyy]

for what its worth, I think it would be helpful for the maintenance of the README if we added the badges to each project, something along the lines of:

ORM

Libraries that implement Object-Relational Mapping or datamapping techniques.

name	description	report card	go doc	coverage
marlow	orm generator

also was thinking that this badge can be placed in the README of projects who have been added to the list:

[PotHix]

Great idea @dadleyy! It would help a lot to keep the list in a good state.

We could also schedule some monthly cleaning for those who don't comply with our standards.

[cassiobotaro]

README loading can be very slow, and badges have cache. I believe that people who choose a library without quality standards should report for us. People are always better than technology.

[PotHix]

I believe that people who choose a library without quality standards should report for us.

In this case, we will make people choose a library from an awesome list just to find out it's not awesome. It doesn't look a good UX for me.

README loading can be very slow

We should try a PoC first just to understand the size of the problem.

[IssueHuntBot]

@rororofff has funded $10.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.

[hewiefreeman]

If nobody is on this task I could help by starting a Go service which would quality check all GitHub projects linked in an MD file every 24 hours.

If I'm not mistaken with any of the metrics, It would be something like:

1. Run goreportcard on project and fail if:
   • project grade is under B+
   • or gofmt is under 80%
   • or govet is under 100%
   • or golint is under 90%
   • or liscense is under 100%
   • or ineffassign is under 90%
   • or misspell is under 95%
2. Somehow run go test -cover through a bash script and get the results in Go and fail if coverage is less than 70% and the report card is not an A+

Any thoughts?

[pjebs]

Some packages have good reason why they can't get that level of code coverage

[avelino]

Some packages have good reason why they can't get that level of code coverage

@pjebs evolve your affirmation, describe the reason, only then can we update our contribution document
We analyze all the PR humanely, the projects that come out of this pattern we study case by case

[mainrs]

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.

Hey there! I got some free time and can curate the list. I will go for this measures as of now. I will modify the test coverage to be 75% for now though and will exclude the need of badges. This should remove a huge amount of libraries at first. PRs can be created to add the badges to their readme's after that.

Are you guys ok with that? @avelino?
I can write a small tool to do it automatically so doing periodic updates like someone mentioned in #2649 could be possible.

[dentych]

What is going on with this list? The pull requests are piling up and many libraries are no longer maintained. The overall state of this list is rapidly decaying. It seems as if there are plenty of people who are willing to help - what's going to happen?

[ceriath]

There are some comments in #2718 about the issue of maintainer activity. Basically, there are only 2 or 3 people who actually still work on this list on a regular basis. If they don't find the time to do so, we end up in this exact situation.
I'd like to add some more people, but unfortunately, i do not have the permissions to do so.

[tdewolff]

See #2734 for an attempt to clean up some subpar packages.

[mrKappen]

I am curious about projects that haven't been updated in years. If no one is maintaining them, should they still be included on the list?

[avelino]

It's a delicate subject, it has a project that hasn't been updated for many years and works super well.

But it would be interesting to have software to help us identify these projects and open an issue automatically to understand the time of the project, if the issue is not answered in X time with positive comment could be removed.

@mrKappen do you have any proposal to eat can do this?

[mrKappen]

I think if a project has not received any commits for over a year, it might be a good idea to at least investigate it (perhaps new security vulnerabilities might have popped up). I like the idea of running a script which would notify you of such projects and automatically create an issue to investigate. Where might be a good place to host such a script?

[avelino]

@mrKappen can host at the awesome-go repository (at the root)

[mrKappen]

Would it make sense to add this as a test to repo_tests.go? If a listed repository fails a certain condition (ex. time from latest commit > 1 year) then fail?

[avelino]

Would it make sense to add this as a test to repo_tests.go? If a listed repository fails a certain condition (ex. time from latest commit > 1 year) then fail?

I don't think it's good to put it in repo_tests.go so we don't run each PR, we'll do it in a new binary (ex last_commit.go, but write test 😄 ), so I put it to run periodically in a server.

[pjebs]

Some packages are featured complete and considered stable, hence no commits such as my https://github.com/rocketlaunchr/remember-go . I won't be updating it.

[mrKappen]

Hey @avelino I added a test script (not in repo_test.go) which goes through the list of repositories and creates an issue to investigate if the repository has not had a commit in over a year. I would love your feedback

[avelino]

Hey @avelino I added a test script (not in repo_test.go) which goes through the list of repositories and creates an issue to investigate if the repository has not had a commit in over a year. I would love your feedback

I've created a new issue to discuss this new feature, let's move this communication there #3211

[IssueHuntBot]

@andreas-jonsson has funded $2.00 to this issue.

---

• Submit pull request via IssueHunt to receive this reward.
• Want to contribute? Chip in to this issue via IssueHunt.
• Checkout the IssueHunt Issue Explorer to see more funded issues.
• Need help from developers? Add your repository on IssueHunt to raise funds.