undefined | Better HN

0 pointsCodesInChaos2d ago0 comments

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 PRs that were closed without getting merged should be held against the account somehow (perhaps via a "close as unwelcome" option for the maintainer).

0 comments

9 comments · 3 top-level

freedomben2d ago· 5 in thread

> 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

CodesInChaosOP2d ago

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.

Tade01d ago

Ultimately what kills any effort to curb this behaviour is the fact that the perpetrator can always open another account.

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.

danuker2d ago

Really it should be a "report as spam" option

dleeftink2d ago

Hence the cooldown period? I think the mechanism proposed here should be perfectly fine for targeted PRs, while mitigating those that sit above baseline.

RugnirViking1d ago

I assume the idea is that you probably weren't doing that 20+ times a day. For me, I was raising at most one or two open source PRs per week at most, and I only had time to focus on one or two repos during that time. I think thats a good baseline, with a big overhead for exceptional circumstance, but I don't see a world where someone should be able to make 10 PRs a day, every day, for weeks

jdxcode2d ago· 1 in thread

Your proposal wouldn't help me at all. I wouldn't say that the problem I'm having is even "spam" per se. (For context I receive hundreds of PRs each week across my OSS projects like mise)

In my case I sometimes get a flurry of PRs from over-exuberant contributors, not necessarily low quality even! Using this I can at least put some back-pressure on that and help keep things more fair across my contributors.

ares6232d ago

why not both?

QuantumNoodle2d ago

Good point. I've (even with agents) never made more than like 5 PRs in one day internal to a company and if I have they typically included accompanying proto or submodule changes. Heck give a factor of safety of 2x and cap at 10 daily PRs per account for repos that youre "untrusted"

j / k navigate · click thread line to collapse