3 ms·

> 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

> 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

dleeftink 4mo 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.
CodesInChaos 4mo 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.
- danuker 4mo ago
  Really it should be a "report as spam" option
- Tade0 4mo 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.
RugnirViking 4mo 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

dleeftink 4mo 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.

CodesInChaos 4mo 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.

danuker 4mo ago
Really it should be a "report as spam" option
Tade0 4mo 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.

RugnirViking 4mo 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