4 ms·

[flagged]

by halapro 5mo ago

[flagged]

jmuguy 5mo ago
This is the correct assessment. This is not up to the open source community or individual projects to "figure out", any more than its up to me to figure out how not to get spam email.
- 20k 5mo ago
  Yeah well, our corporate overlords have decided that you're going to take your slop whether you want it or not, so its very much up to us to figure out. Capitalism isn't going to jump off the disaster train any time soon
- pydry 5mo ago
  Github team are seemingly too busy fighting downtime with ever more slop.
drusepth 5mo ago
What is the benefit of deleting a PR over just closing it? It seems like closing has the benefit of signaling what kinds of PRs aren't acceptable, which deleting would lose.
- TuxSH 5mo ago
  Closing a PR or issue still makes it discoverable in PR/issue search results, as opposed to deleting an issue.
  - karussell 5mo ago
    This. But OP wanted special requirements to open a PR. I.e. if those requirements are not met the PR is never visible to all and so admins can reject spam PRs without giving them a platform.
    - halapro 5mo ago
      We occasionally get traditional SPAM PRs pointing to their product. In that case it is very useful to clear out title, PR body and reset the commits as well, so none of that appears on the repo. This is time consuming. Unfortunately the PR and the PR author will forever be listed there and linking to their product anyway.
      - TuxSH 5mo ago
        > Unfortunately the PR and the PR author will forever be listed there If they've been doing that to the other repo (and especially if they're just a spam account), there's a good chance using the "report" button and/or contacting GH support directly can yield positive results, up to the spam account being deleted (and the PR is usually deleted). Unfortunately this doesn't scale.
        halapro 5mo ago
        > Unfortunately this doesn't scale Correct. I used to report them, but 3/4 years ago they made it more difficult to report anything because you have to explain what's wrong even when it's very clear.
- halapro 5mo ago
  In the future, when you're looking at past PRs, you'll end up with a list of closed PRs that look legitimate from their titles. You'll waste time opening each one to figure out why it was closed. This is particularly annoying because PRs also show up in the issue and in the issue list as "this issue has 3 PRs that will close it", when it's all. just. spam.
moraesc 5mo ago
We’re currently working on a feature that lets admins archive PRs. The goal is to give maintainers more control over how they manage contributions in their repositories. Archived PRs would be visible to admins only, so maintainers still have access to contributor history for auditing purposes and to meet any organizational or compliance requirements. Would this be helpful for you?
- karussell 5mo ago
  Not OP but requested this feature since years. Your suggestion would help a bit but I would prefer the opposite: before someone can 'pollute' my pull request space and draw attention from subscribers I would prefer an acceptance step (just like a moderator on a forum) instead of having to archive the PRs. This is especially important as (AI) spam increases and just because I am away for a few days or weeks I don't want those PRs lurking around.
  - darccio 5mo ago
    A PR staging area. This would be a good step forward.
    - bloppe 5mo ago
      That kinda sounds like draft PRs. You can make all PRs drafts by default. I guess it would be cool to have a setting where only maintainers can change it to ready-for-review.
      - halapro 5mo ago
        If the PR exists on my repo, it's already too late. Either you let me block 6-month old accounts from opening PRs, or you let me delete them. PRs, draft or not, show up in searches and spammers can continue opening new ones as well as leaving comments on them.
- hpjev 5mo ago
  I can only speak for myself, being a maintainer of a project in the crypto space. We are getting spammed with AI slop and also scam comments (though this lessened for some reason). My usual experience is this: 1. We open an issue that needs to be fixed 2. slop bots create multiple slop PRs 3. slop bots spam comments on the issues, pointing to their slop PRs The only general methods for preventing this are are restricting PR's (not comments, I believe) to contributors - which is a hassle to maintain, and restricting to older accounts - which doesn't work because the bot accounts are not newly created. Then we need to perform _way too many_ just to get rid of the slop: - navigate multiple pages and confirmations to ban the account from our org - open each PR manually - close it manually This takes at least 15 clicks and is made _so much worse_ by how slooooooooow the UI is. Every click takes 2 seconds!!! How can "ban this account and delete everything it ever did" be more than a max of 2 clicks? What we really need is a "locked down mode" where every interaction (PR, issue, comment) with the repo that isn't from maintainers or specifically whitelisted people goes into a moderation queue. Maintainers can confirm or deny the action using a single click (which does not take 2 fucking seconds to load).
tommica 5mo ago
I'd imagine this is not a simple problem to solve, and legacy code is probably causing a massive headache too
- halapro 5mo ago
  They do have ways to limit interactions already, but they work on a whitelist level rather than dynamically based on user "score" (account age, contribution history, etc). If a user gets their comments deleted and blocked from organizations, GitHub should already know it's a spammer.

[flagged]

by halapro 5mo ago

[flagged]

This is the correct assessment. This is not up to the open source community or individual projects to "figure out", any more than its up to me to figure out how not to get spam email.

20k 5mo ago
Yeah well, our corporate overlords have decided that you're going to take your slop whether you want it or not, so its very much up to us to figure out. Capitalism isn't going to jump off the disaster train any time soon
pydry 5mo ago
Github team are seemingly too busy fighting downtime with ever more slop.

drusepth 5mo ago

What is the benefit of deleting a PR over just closing it? It seems like closing has the benefit of signaling what kinds of PRs aren't acceptable, which deleting would lose.

TuxSH 5mo ago
Closing a PR or issue still makes it discoverable in PR/issue search results, as opposed to deleting an issue.
- karussell 5mo ago
  This. But OP wanted special requirements to open a PR. I.e. if those requirements are not met the PR is never visible to all and so admins can reject spam PRs without giving them a platform.
  - halapro 5mo ago
    We occasionally get traditional SPAM PRs pointing to their product. In that case it is very useful to clear out title, PR body and reset the commits as well, so none of that appears on the repo. This is time consuming. Unfortunately the PR and the PR author will forever be listed there and linking to their product anyway.
    - TuxSH 5mo ago
      > Unfortunately the PR and the PR author will forever be listed there If they've been doing that to the other repo (and especially if they're just a spam account), there's a good chance using the "report" button and/or contacting GH support directly can yield positive results, up to the spam account being deleted (and the PR is usually deleted). Unfortunately this doesn't scale.
      - halapro 5mo ago
        > Unfortunately this doesn't scale Correct. I used to report them, but 3/4 years ago they made it more difficult to report anything because you have to explain what's wrong even when it's very clear.
halapro 5mo ago
In the future, when you're looking at past PRs, you'll end up with a list of closed PRs that look legitimate from their titles. You'll waste time opening each one to figure out why it was closed. This is particularly annoying because PRs also show up in the issue and in the issue list as "this issue has 3 PRs that will close it", when it's all. just. spam.

moraesc 5mo ago

We’re currently working on a feature that lets admins archive PRs. The goal is to give maintainers more control over how they manage contributions in their repositories. Archived PRs would be visible to admins only, so maintainers still have access to contributor history for auditing purposes and to meet any organizational or compliance requirements. Would this be helpful for you?

karussell 5mo ago
Not OP but requested this feature since years. Your suggestion would help a bit but I would prefer the opposite: before someone can 'pollute' my pull request space and draw attention from subscribers I would prefer an acceptance step (just like a moderator on a forum) instead of having to archive the PRs. This is especially important as (AI) spam increases and just because I am away for a few days or weeks I don't want those PRs lurking around.
- darccio 5mo ago
  A PR staging area. This would be a good step forward.
  - bloppe 5mo ago
    That kinda sounds like draft PRs. You can make all PRs drafts by default. I guess it would be cool to have a setting where only maintainers can change it to ready-for-review.
    - halapro 5mo ago
      If the PR exists on my repo, it's already too late. Either you let me block 6-month old accounts from opening PRs, or you let me delete them. PRs, draft or not, show up in searches and spammers can continue opening new ones as well as leaving comments on them.
hpjev 5mo ago
I can only speak for myself, being a maintainer of a project in the crypto space. We are getting spammed with AI slop and also scam comments (though this lessened for some reason). My usual experience is this: 1. We open an issue that needs to be fixed 2. slop bots create multiple slop PRs 3. slop bots spam comments on the issues, pointing to their slop PRs The only general methods for preventing this are are restricting PR's (not comments, I believe) to contributors - which is a hassle to maintain, and restricting to older accounts - which doesn't work because the bot accounts are not newly created. Then we need to perform _way too many_ just to get rid of the slop: - navigate multiple pages and confirmations to ban the account from our org - open each PR manually - close it manually This takes at least 15 clicks and is made _so much worse_ by how slooooooooow the UI is. Every click takes 2 seconds!!! How can "ban this account and delete everything it ever did" be more than a max of 2 clicks? What we really need is a "locked down mode" where every interaction (PR, issue, comment) with the repo that isn't from maintainers or specifically whitelisted people goes into a moderation queue. Maintainers can confirm or deny the action using a single click (which does not take 2 fucking seconds to load).

tommica 5mo ago

I'd imagine this is not a simple problem to solve, and legacy code is probably causing a massive headache too

halapro 5mo ago
They do have ways to limit interactions already, but they work on a whitelist level rather than dynamically based on user "score" (account age, contribution history, etc). If a user gets their comments deleted and blocked from organizations, GitHub should already know it's a spammer.