Add a new contribution rule: Restrict projects that are unused and are not unique from being submitted

[yassinebenaid]

A lot of PRs are submitting new projects. And, in a lot of cases, they are just redundant packages that do something one or more popular projects are doing it years before.

An example would be packages for task management (cron implementations), reflection packages, config files loaders, web frameworks, dependency injection and many more.

These are the top categories that receive the most of new projects. That is not a problem, until it is.

A lot of newly submitted packages are doing the exact same thing, may be some API differences but still have the same interface, the same functionality and for the same use case.

So my suggestion is to add a new contribution rules that indicate:

1. Not to submit new projects that don't have any or very few active users (we can specify a minimum threshold of stars for example)
2. We may break rule number 1 if, the project is offering a unique functionality that none or only few actively maintained projects are offering.
3. We may break rules number 1 and 2, if the project is considered better that others in some way (performance, adds new functionalities others are missing, ... etc)

Of course we can break all above rules in very rare cases depending on situation. However, PRs that break above rules will be closed.

Any thoughts @avelino @phanirithvij

[yassinebenaid]

Regarding: #5469

[phanirithvij]

"not unique" is not something I can decide without keeping all the similar packages in the same category in my head when reviewing.
It is very subjective, I am against this, if the project meets the quality standards it's fine if it is not unique, we can always remove it later, we are not the patent office.

github stars can be botted and bought and also it adds bias to the one approving the project, we ought to be more careful when considering adding a hard rule on it.

So the one suggestion I can think of is a minimum of 5 months since first commit, to filter out projects which submit as soon as they make it public, or within a week of releasing it. If they do submit it we close the pr with a message indicating this, requesting to re-submit. We don't need to keep track of those, they will re-submit if they wish.

And some people are under the impression of using awesome-go for growth, i.e. they want to be in the list so their new project can grow.
I am against this, and it should be the other way around, i.e. if they already are used widely and meet all quality standards then it can be included in awesome-go.

We are curating good tools/utilities/projects which we are sure will be widely useful because we can see they are being used and developed actively. So this should eliminate any new projects right off the bat.

[yassinebenaid]

Alright, I agree. I will create a PR adding this to CONTRIBUTING.md and request for review.

[ccoVeille]

About what is described in the issue (not in the replies in comment). it depends on what you want to achieve

• Having fewer projects submitted
• write rules that are somehow already applied
• being able to quote a reason when refusing a project
• avoid poor project to be merged even if they comply existing rules
• allow maintainer to remove a project while adding a new one, if it is better.

If the idea is only the first one, I'm afraid it won't work. People don't read documentation. They always want to promote their tools, without knowing or even trying to know another exists and is very popular and used.

So if your will is to provide a guidance to maintainers, I'm ok. Otherwise, I'm afraid it might be useless.

But yes, the 5 months rules could be interesting