Prevent bulk spam PR's

[cllns]

Select Topic Area

Product Feedback

Body

A user (https://github.com/JasonnnW3000) recently opened 1881 PR's against seemingly random popular repos, making an invalid date change to MIT license files, updating the year to 2025 when it's not necessary. They admit to "Padding my changed LOC! 😛" as well.

Here's the list of the PR's: https://github.com/pulls?q=is%3Aopen+is%3Apr+author%3AJasonnnW3000+archived%3Afalse+

I feel like GitHub could rate limit this pretty easily, especially with essentially identical diffs and PR descriptions. It was clearly scripted spam, many simple heuristics could catch and stop this.

Here's the PR that personally affected me, as a maintainer of this repo: hanami/hanami#1494
Here's a PR that has some more discussion about this, that people are using for cross-referencing this issue: pytest-dev/pytest#13097 (comment)

Almost all of us are volunteering to do OSS work; we're not compensated for it at all. Assuming it takes 1 person 5 minutes to review and close (and context switch) each of these PR's, that's 1881 PR's * 5 minutes = 9405 minutes or 157 hours, which is 6.5+ days of collective time this one user is wasting through spam.

In some of the PR's, I've seen people linking to this Discussion post, which is only available for people in the GitHub "Maintainers" community. I've just requested to join that, but I think this issue is worth a public discussion as well.

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐

[thaJeztah]

I feel like GitHub could rate limit this pretty easily, especially with essentially identical diffs and PR descriptions

A new account forking more than 1600 repositories should probably raise some flags somewhere.

I think this particular case is definitely troublesome, because each individual PR could be considered "legit", and some of them may be "ok", but mostly "by accident"; it's clearly with the intent to get as many PRs as possible. And the amount of time wasted by people even looking at those PRs; in some cases discussing the changes and where needed finding links to reference about "why the year should NOT be updated" is just a massive waste of time.

[cllns]

It looks like all the spam issues have been (manually) deleted by GitHub staff, and the user's account has been deleted as well.

While this is good, I still think GitHub should proactively stop these kind of spam PR's, since it cost many OSS maintainers valuable time (on a global holiday also).

It's obviously hard to stop all spam PR's, but the scope could've been limited to dozens rather than thousands of projects being affected.

cc/ @webknjaz who I interacted with on one of the now-deleted PR's

[windyakin]

The account has been suspended, making it difficult to find the repository where the Pull Request was merged.

The email address was included in the commit message, so you can search for it (I assume the email address is public information since it is included in the commit message).

• https://github.com/search?q=sufssl04%40gmail.com&type=commits

Not all Pull Requests created are harmful.

For example, if you use the format “© {first published year}-{current year} {publisher name}” for copyright, it seems fine (But the current year is not necessarily required by the UCC).

[LitoMore]

Below is my comment on https://github.com/community/maintainers/discussions/442#discussioncomment-11711525:

I'm concerned about this. See approving workflow runs from public forks. Note that the user account is fresh; it would be a security issue if this user had other intentions.

It is better to keep an eye on those low-quality contributors.

[mootari]

Similar story for https://github.com/shaymolcho. The account created nearly 50 very likely automated PRs over the last four days, all along the lines of "Added missing periods for text consistency": https://github.com/pulls?q=is%3Apr+author%3Ashaymolcho+archived%3Afalse+

[gms1]

several spam issues opened per minute by different users in
https://github.com/helm/helm/issues
repo. This seems to have been going on for days, why doesn't anyone from Github notice this?

[LitoMore]

I've forwarded your report to the GitHub Maintainers community. They will handle this in a short time.