Repository navigation
feature: add a GitHub action to quell spam PRs #5449
Description
Problem
I was scrolling through Twitter and someone posted about the spam PR.
Possible Solution
Implement this GitHub action. It'll lessen the workload for maintainers.
Reacted by Vijay Kv, Pj-Mathematician, Faisal Afroz, Samir Dahal, GiriPrasath.D, Jes015, Ricardo Fernández Serrata, Lovepreet Singh, Deepak_, Nate and 16 more
Reacted by Wu Tingfeng, Nam Le, Emil Sierżęga, zerokaze and Kangcheng Xu
Reacted by Ulises Gascón, Ajani Bilby, Vadims Casecnikovs (Vadim Chashechnikov), Pj-Mathematician, Hozefa, Jes015, mhguelleh, Mert Can Altin, Phlphat746, modernToujours and 2 more
Reacted by Ricardo Fernández Serrata
Activity
wesleytodd commentedon Feb 6, 2024
I am not sure we need an action for this unless there is an action which does more than that one (like spam detection with ai or something). It is easy to delete/close/lock with as many clicks as it is to comment and we don't need an additional third party action (added security risk and maintenance) to do it right?
iammohan01 commentedon Feb 6, 2024
wesleytodd commentedon Feb 6, 2024
krzysdz commentedon Feb 6, 2024
Not sure about AI spam detection, but almost all of these PRs update the readme, have default name (Update filename), change only a single line and have no description, so it should be rather easy to close them automatically.
Most authors of these PRs have a repsitory called "localrepo", so that's another rule that could be used to detect spam from this source (Apna College).
wesleytodd commentedon Feb 6, 2024
Yeah this is a one-off issue of the day. Spam PRs have been a problem for years and they come in different varieties. This is why I am hesitant do add an action for this as I would rather ask GitHub for better spam management tooling.
TimGels commentedon Feb 6, 2024
CBID2 commentedon Feb 6, 2024
Hey @wesleytodd. I found this on X: https://twitter.com/github/status/1311772722234560517
Maybe that could work?
UlisesGascon commentedon Feb 6, 2024
Agree with @wesleytodd. The issue is quite complex because the moderation in GitHub is not an easy thing:
So, I think that we are quite limited on how much we can do with GitHub actions in this case. There are other scenarios that are less frequent but more prone to use GitHub Actions to moderate, for example when people do comments that include offensive content or heavily language. In most projects that I am involved the moderation is done by the humans behind the project or a specific team that volunteer to do it, it is a heavy job. The same way as it is hard to keep a slack/discord/gitter community channel a safe space by moderating content.
wesleytodd commentedon Feb 6, 2024
I think historically the express project has not needed the same style of moderation as things like Node.js does. There have been less contentious discussions and mostly the CoC violations have come from folks outside the project so it was relatively simple to ban and move on. I don't think we need to immediately spin up a moderation team but I do think that the Triage team and TC should have the tools to properly moderate. Right now I don't think we have that well in hand. I believe that we can add this to the list of TODOs to address after we can get next weeks TC meeting organized and finished.
Are we in agreement that a GH Action is most likely not the direction we would want to take to solve this problem?
UlisesGascon commentedon Feb 6, 2024
Yes, we can add it to the TODO list and start to work on it in few weeks
+1 from me
krzysdz commentedon Feb 6, 2024
Maybe a pull reqest template would make some people think before creating a PR?
On the other hand, it doesn't look like those who spam with pull requests will even bother to read it and they'll probably just click "Create pull reqest" with unedited description.
QuantGeekDev commentedon Feb 6, 2024
krzysdz commentedon Feb 6, 2024
wesleytodd commentedon Feb 6, 2024
Doesn't need to stop the conversation, but since we specifically don't want to use a GHA to do this then this issue is complete. There are more threads to follow up on, but I think we can do that in other discussions more specific to those.
48 remaining items
wesleytodd commentedon Feb 18, 2024
Hey folks, just to update you: We have a thread open with GitHub support where they are passing along our requests to the various product teams on how to improve the moderation features. I personally am still 👎 on an action which auto closes PRs as it is both a maintenance burden and something best handled by features on GitHub's side. We are focused right now on landing some governance changes and will be following up with re-constituting the triage team. I think ideally this decision is left up to the triage team members. So likely there will not be action on this or the PR until we can get that team organized again. If you are interested in helping that please follow the instructions to get involved there (as some of you already have, thank you very much for that).
dougwilson commentedon Feb 18, 2024
They have slowed down too for the time being, the last one already is two days old.
nkroker commentedon Feb 23, 2024
wesleytodd commentedon Feb 23, 2024
jonchurch commentedon Mar 26, 2024
Closing as not planned.
Many words have been written now in this issue and others about auto-closing spam PRs, and we have come to the same conclusion every time. It is trivial to implement, but is a sledgehammer approach for what is now a mosquitto level annoyance. Closing and locking a handful of spam issues/PRs now and then is the easiest thing a maitainer will be doing that day, so it doesn't save much by labor.
There is very little benefit in having an auto-close action. It will still spam people's Github notifications no matter if it's closed and locked at the speed of a human or a machine. The only thing we'd prevent there is people commenting disparagingly on the PR before it gets locked by a human, generating more notifications. We haven't had any of that in the past couple weeks (we did get some hostile comments when this topic was trending originally, which it no longer is).
The PRs are still coming, but intermittently. The storm has passed, this can be reevaluated if another flood happens in the future from the previous source or any other.
Thank you all for your eagerness to help. If you want an ear to the ground on things that the project is prioritizing and possibly looking for help with, peruse the Discussions repo https://github.com/expressjs/discussions/issues
not7cd commentedon Apr 19, 2024
This can be reconsidered with the use of
label-action. By labelling those PRs this action can create a meaningful message to the spammer to inform them why it's getting closed.See an example from Renovate:
wesleytodd commentedon Apr 23, 2024
Hey @not7cd,
I love the idea of "create a meaningful message to the spammer to inform them why it's getting closed". Would you be willing to sign up to own this and help participate in the project to maintain the tooling? The main thing here is that closing a few spam PRs is a simple but short term thing. Working on setting up automation means time taken away from much more important project priorities we have right now. So it is mostly a prioritization thing.
So far the folks who showed up to make noise about ways to "solve" this problem have not showed up to reply with this sort of context in the spam PRs. If anyone in the threads wants to start posting these prewritten messages to the authors then we (the maintainers) can stop with our current approach of closing them as spam. This would save us a lot of time and help those users learn, but it is work and we are volunteers.
For everyone in this thread, please we need your help: