[Repository] Limit/prevent spam issues/PRs

[GuillaumeDua]

Motivation

• Limit/constraint the amount of new irrelevant issues and PRs
• Thus avoid unnecessary notifications and emails received by the ~2k watchers of this repository
• Yet ensure the solution won't be an impediment for legit contributors

Context

Roughly checking on:

• Closed-as-not-planned issues
• Unmerged PRs

Some recurring characteristics emerge:

• The account user was just created
• Short issue/PR name: most likely, a single word
  • contributor name, possibly shortened
  • generic ("Git", "practice", "projects", "Cpp", "ccc", "Hello World", "Hi", "Halo", etc.)
• Short issue/PR body
• The issue/PR is the first one of this user, ever.
• There's no previous nor further activity on the user's account.

And sometimes:

• The contributor name is composed like <some_indian_name>_?\d+, but this cannot constitute a criterion in any way.

Suggested solutions

Turn on moderation settings

• See interaction limits, to enable Limit to existing users

Disable blank issue/PR template

From my perspective, a (bunch of) dedicated template issue/PRs with many non-empty fields are a good way to avoid unnecessary issues and/or PRs.

Add a dedicated anti-spam github-action

Such a github-action would perform several checks, as acceptance criteria.

Technically it could rely on actions/github-script@v7 (and octokit) to use the github rest API.

The repo's example here automatically add a comment to PR created by new contributors.

We can then implement other criterions, as the one listed in the Context section above.

What if the checks does not pass ?

• Either add a dedicated label suspicious to the issue or PR.
• Or immediately rejects the issue/PR by closing it,
  possibly adding an automated comment describing the reason, and pointing to the "how to contribute" guideline.

Additional thoughts

• Either solution might make the spammers always find new ways to meet such acceptance criterias and keep on spamming, over and over again ?

[jwakely]

It would be great if we can stop nonsense like #2257, #2241, #2254, #2252, #2249, #2238, #2225 etc. etc. etc.

[GuillaumeDua]

I made some experiments, available with the draft PR #2259 (disclaimer, I'm not a JS developer).

• Ok example: all checks pass
• Rejected example: 1 check failed, others pass

From that point, I think we need to:

• Consider using first the non-CI options mentioned above
• Be really clear on the acceptance criteria must be, so we don't imped legit users.

From my perspective, either suggested solution would prevent nonsenses like #2255 .