Awesome-go: None of the owners is reviewing PRs?

[panjf2000]

Dear owners of Awesome-Go,

I saw the last merged PR was almost a month ago and no one is reviewing those opened PRs, including mine: #2715, some of those were also opened a month ago, not pushing you just want to know what is happening here?

Thanks~

[SonicRoshan]

Pretty true, even my PR has not been reviewed

[miry]

@panjf2000 Try this one: https://github.com/uhub/awesome-go

[kirillDanshin]

I’m going to review PRs today.

[panjf2000]

@kirillDanshin
Thanks for the reply.
and thanks @miry, but I still want to deal with this repo.

[kirillDanshin]

Just a note about what I'm doing right now.

As you may notice, I'm closing all old PRs with any issues. In this way, I can clean up our PRs. If I closed your issue, please don't be offended, and feel free to open a new one once all problems will be fixed.

I know that we have a rule that requires review by at least 2 maintainers, but as we all can notice, there's a bunch of PRs that did not received an answer from our team or wasn't reviewed at all for more than a month. I see that this rule doesn't work well due to the fact that our maintainers are not obligated by any means to really review anything, so requiring two maintainers to review something basically means that our average response time is going to be weeks, while we require a response in a strictly defined period of time.

Currently I'm merging awesome good quality projects, and I hope that reduced amount of open PRs will help our maintainers team to review PRs faster. As we know, the more open issues or PRs a human see, the more difficult it will be to that human to begin working on them. Hope my idea works 😄

In the future, feel free to ping me if you're waiting for a PR review too long, I'll try to help you.

[ceriath]

thanks @kirillDanshin for the work you did today.

However, this is still an issue of this repository. In the last few months, @cassiobotaro and me handled most of the workload. Due to some personal circumstances, i did not have any time to review anything, which resulted in a lot of PRs to remain unreviewed for over a month. It's true, that i tried to spend at least of bit of the little free time, that i had, reviewing, but seeing 60 open PRs completely ignored basically, made me feel bad. I will be able to contribute again more actively in a week or two, but it does not solve the issue by any means, since having one or two active maintainers is far too less to effectively handle this repository with its current rules and standards.

Either we should change the rule, that 2 reviews are required, or we need some more (actively) helping hands.

[kirillDanshin]

@ceriath actually, I think we should revert that 2 reviewers requirement, as basically I violated this rule a dozen times just to revive our PR pool. it's sounds insane.
searching for new maintainers is difficult, currently according to our MAINTAINERS list, we have 11 of them, but it doesn't help currently. I assume, it's because of quite difficult time around the world. I was away from awesome-go for a quite some time due to personal problems; I still didn't solve them, but I see that if I will not work on awesome-go, there will be a huge list or PRs just totally ignored, which makes me feel bad 'cause the entire community done lots and lots of work to make awesome-go _the_ place to go for a new library.
Also, I think we should get us a way to communicate on daily basis and just try to manage this project in a more stable way

[ceriath]

Maybe we should also consider to move the active list to an organisation, so it will be easier to manage. I agree that we should just merge things if we don't find any issues, but it still feels wrong to me to just change the rules this easily without approval of the repository owner.

I am definitely willing to help bringing the project back on track for that matter and I'll be actively reviewing PRs as soon as its possible to me again.

[kirillDanshin]

Maybe we should also consider to move the active list to an organisation, so it will be easier to manage.

I don't think it's right to discuss this idea without @avelino.

I agree that we should just merge things if we don't find any issues, but it still feels wrong to me to just change the rules this easily without approval of the repository owner.

We don't change the rules, all we can is to bring a PR with changes and ask @avelino if he agrees.

P.S. I don't think it's related to the quality standard, actually

[kirillDanshin]

Well, I think we're good for next couple of hours: we have 14 open PRs, 13 of them is pending submitter response and 1 is waiting for an @avelino's decision.

in the meantime, we need to find a way to consistently maintain the project.

[panjf2000]

Thanks @kirillDanshin and @ceriath for your personal efforts in awesome-go repo, and all other maintainers as well.

And about the solution you are seeking to solve this issue, here is my proposal: I agree with @kirillDanshin, revert that 2 reviewers requirement and since I am an active visitor to awesome-go and a beneficiary from it, I can help you with some trifles, for instance, I assist in notifying you when the PR list reaches a massive amount by any contact means you feel comfortable, and I will check out the recent merged PRs, if I find something not up to standard among them, I also notify you guys, I will do this per day/week, is it ok?

[dentych]

@panjf2000 Try this one: https://github.com/uhub/awesome-go

This is what I fear will happen if something is not soon done with this repo. A multitude of derivatives. In my opinion, this nullifies the purpose of the list - if you anyway have to go to 20 different lists to find libraries, you might as well not have the lists.

The thing that is so great about open source is that we can come together as a community and work towards a common goal. Creating spin-off lists is not really working together, but rather segregation of the community.

I think @ceriath's idea with an organisation is great. If the collaborator group is the "leader group", and any and all decisions can be taken by a matter of vote, then no single individual will be the bottleneck.

That's just my two cents. I would really hate to see this list die, as it is both mine and many others' goto list when it comes to great Go libraries :)

[avelino]

We need contributors to revise PR, lately I'm out of time, sorry. Who has an interest in helping keep telling me that I add

[panjf2000]

@avelino

Who has an interest in helping keep telling me that I add

Do you mean a new reviewer of awesome-go?

[ceriath]

@panjf2000 apparently.
@avelino when you find the time, please read @dentych's and my suggestion

[panjf2000]

@avelino
Then I am applying for that 🙋‍♂️

[avelino]

• I agree that we should review the rule of 2 reviewers, @ceriath @kirillDanshin do you update the Contribution Guidelines?
• Move to an organization in the management force, do not find it interesting to have an organization for only one Reporitorio, it would be interesting @golang have an organization for packages maintained by the community, but has not
• @panjf2000 I added you as a collaborator

[avelino]

Do we have any more points to complement this issue? Can we close?

I see we need more collaborators, I would like to promote more people by karma

[panjf2000]

So do we make any conclusion? Like the minimum number of reviewers to review a PR?

[avelino]

To me it was clear that:

• we need more reviewers
• we download the number of reviewers, to leave with menas barriers (we must trust 100% in our maintainers)

Does anyone have any more recommendations?

About migrating to an organization: I think it's important but we need to understand which makes sense and accept us given that in the past I spoke with Golang and we were not welcomed, in the end I agreed with the point of view of the maintainers of the core Golang, If awesome-go was there the community might think it's a list of libraries recommended by the language Go, awesome-go is not that but a list maintained by the community

[panjf2000]

@avelino
You get my vote in that decision of reducing the number of reviewers to a PR but my suggestion is that we should check up the merged list regularly to remove those unqualified repositories, as for the organization thing, we have to maintain the status(still keep this repo under your personal Github account) since the Golang team hasn't accepted awesome-go as an official repo yet.

[deankarn]

Hey all, sorry I don't chime in all that often my job and open source work keep me very busy and when I'm not working spend my time with my two boys.

As for moving to an organization or not, I don't think it matters one way or the other, will leave that decision to @avelino

I agree a few more reviewers may be necessary given the number of requests and I'm sure the current maintainers' busy lives/schedules.

I think that having the need for 2 reviewers is slowing the process down and vote to reduce to 1.

I think that perhaps we can leverage a little bit more automation overall to help the flow also. It seems that most of the checklist steps have to be performed manually by each reviewer but see no reason 95% of them could not be automated and we could write a script or program that the CI executes when the PR is made. an example flow:

1. PR made
2. CI runs
3. repo is downloaded
4. automatically check for the existence of a README.md, LICENSE etc...
5. parse the README.md to ensure the links are present that are expected
6. rust tests `go test -race ./...
7. produce our own code coverage and check it's up to the standards
8. whatever else is needed or desired
9. Post the checklist as a comment using the GitHub API.
10. If Unsuccessful include a cc to the submitter and add a label to the PR quality standard
11. If Successful include a cc to the owners/maintainers team/group and add a label to the PR Ready for Review. Also, remove any quality standard label from a previous revision/commit.

This has the benefits of:

• reducing what's needed for the maintainers to manually check
• provide immediate feedback to our contributors about what needs to be fixed or if their all good
• Allows maintainers to filter quickly by label the projects that are ready to be reviewed manually,
• BONUS: the script could be run independently of the CI, in a different mode, which will do the same checks but produce a PR to remove the repo if the standards are violated or slip below a threshold and cc the maintainer giving them a chance to correct the issue or we'll automatically merge the PR after X days or something.

Although it's not perfect it'll probably work 95%+ of the time, there will always be exceptions that need to be handled. In no way am I suggesting a human shouldn't look before merging but we can greatly reduce the humans' workload! 😄

[panjf2000]

@deankarn
I love the idea of automating things with programs/scripts, I think we can take some time to investigate it, finding out a way to reduce the efforts of the human.😆

[avelino]

About talking more, we can use slack for instant communication, but do not like synchronous work, can send me message there but answer when you are online (Async working)

Let's go to slack https://github.com/avelino/awesome-go/issues/1666