51–56 of 56 posts
The primary spam problem isn't that a single account opens many pull requests on a single repo, but that spammer accounts open many pull requests spread across many repositories. So limiting accounts to a couple of open PRs on my repository won't help much. I'd rather enforce a limit based on the number of PRs that account opened across all public repositories it doesn't have write access to within the last week. And…
The primary spam problem isn't that a single account opens many pull requests on a single repo, but that spammer accounts open many pull requests spread across many repositories. So limiting accounts to a couple of open PRs on my repository won't help much. I'd rather enforce a limit based on the number of PRs that account opened across all public repositories it doesn't have write access to within the last week. And…
Github needs a "Human Trust" score where "AI Slop" label applied to a PR reduces the score and denies all PR's for the next X hours, delay increasing exponentially for every PR labelled with "AI Slop". Repeated "AI Slop" labels given by a maintainer reduces "Human Trust" Score like dropping off a cliff. Every successful merge for a PR spread across N days slowly increases "Human Trust" score. (So a slow of fake merge…
> banned from all PR submissions
So then the person can't even make a PR against their own repository? Or when we're there a maintainer, known contributor, or a member of an organization that might be their workplace?
Earlier quoted context omitted.
Github needs a "Human Trust" score where "AI Slop" label applied to a PR reduces the score and denies all PR's for the next X hours, delay increasing exponentially for every PR labelled with "AI Slop". Repeated "AI Slop" labels given by a maintainer reduces "Human Trust" Score like dropping off a cliff. Every successful merge for a PR spread across N days slowly increases "Human Trust" score. (So a slow of fake merge…
That could be abused the other way against well-intentioned humans. Simply let someone accumulate PRs at a not-abusive rate, and then once enough exist falsely report them all in a day. > banned from all PR submissions So then the person can't even make a PR against their own repository? Or when we're there a maintainer, known contributor, or a member of an organization that might be their workplace?
Obviously ban is only for PRs against other repositories belonging to different users/organization. Not PRs towards same user/org.
The primary spam problem isn't that a single account opens many pull requests on a single repo, but that spammer accounts open many pull requests spread across many repositories. So limiting accounts to a couple of open PRs on my repository won't help much. I'd rather enforce a limit based on the number of PRs that account opened across all public repositories it doesn't have write access to within the last week. And…
> And PRs that were closed without getting merged should be held against the account somehow That strikes me as a bad solution. I've sent plenty of PRs over the last two decades that were things I wasn't sure if upstream wanted or not, but I did the work and wanted to offer it to them. If you get penalized for not having a PR merged, it's going to incentivize selfishness
Earlier quoted context omitted.
> And PRs that were closed without getting merged should be held against the account somehow That strikes me as a bad solution. I've sent plenty of PRs over the last two decades that were things I wasn't sure if upstream wanted or not, but I did the work and wanted to offer it to them. If you get penalized for not having a PR merged, it's going to incentivize selfishness
That's why I suggested an explicit "close as unwelcome" option (label to be bikeshed). And the impact of the rejection should decay over time. In any case, my proposal is a rough sketch of how I'd approach the problem, not a production ready algorithm. But I'd expect even that basic approach to work a lot better than github's approach.
If I was a maintainer of an open-source project, I would have a two-tier system:
-PRs from previous contributors.
-All others, sorted by lines of code, ascending.
Reasoning:
-Large PRs from someone without a track record are rare.
-It's not a huge ask to have people first solve a smaller problem.
-Small PRs are easy to verify - it's especially easy to tell if a given one-liner is impactful or just spam. Should also be easier to summarise it in the title.
-Don't quote me on that but I think LLMs are still bad at clear, concise, meaningful changes.
The primary spam problem isn't that a single account opens many pull requests on a single repo, but that spammer accounts open many pull requests spread across many repositories. So limiting accounts to a couple of open PRs on my repository won't help much. I'd rather enforce a limit based on the number of PRs that account opened across all public repositories it doesn't have write access to within the last week. And…
I think it's more likely a lot of these are well intentioned individuals or people trying to build a resume. They'd want a lot of accepted PRs on one account, not lots of accepted PRs accross a lot of burner accounts