5 ms·

Pull request limits are cutting down the noise

101 points by ingve 4mo ago

mbaloch2136 4mo ago
[dead]
righthand 4mo ago
[flagged]
- MeetingsBrowser 4mo ago
  how so?
  - righthand 4mo ago
    How else would it appear as a popular platform without bots everywhere? If there’s even any minor truth to dead internet theory then it extends to Github most certainly.
arjie 4mo ago
[flagged]
- qazxcvbnmlp 4mo ago
  Being able to submit an issue, description, test criteria along with a token budget would be pretty cool.
  - arjie 4mo ago
    There's an amusing attempt at this here: https://clevercrow.io/ https://clevercrow.io/ It was on HN here: https://news.ycombinator.com/item?id=48621645 https://news.ycombinator.com/item?id=48621645
- csiegert 4mo ago
  There is also the solution of: No merge requests, just feature wishes and bug reports. All code is written solely by the maintainers (with the help of LLMs).
  - parliament32 4mo ago
    Add a mechanism to donate tokens towards the maintainers' LLMs for a particular ticket and this whole class of problems will be resolved all at once.
    - wereHamster 4mo ago
      > Add a mechanism to donate tokens Or donate money. Crazy idea, eh?
      - toomuchtodo 4mo ago
        Some people have tokens but no money. Tokens, like Amazon gift cards and Tide detergent [1], are a form of currency in a way. If people have a currency equivalent they want to spend for your benefit, or the collective benefit, it makes sense (depending on level of effort) to enable them to do so. [1] How Tide Detergent Became a Drug Currency - https://news.ycombinator.com/item?id=5023204 https://news.ycombinator.com/item?id=5023204 - January 2013 (124 comments) (edit: maybe put AI tokens on stablecoin rails as value tokens? could be fun, could move them around instantly between participants on the value rails and could consume them programmatically, if someone implements this idea, buy me a beer!)
        nozzlegear 4mo ago
        > Some people have tokens but no money. This sounds like a piece of worldbuilding from a Daniel Suarez novel. Who has tokens but no money?
        toomuchtodo 4mo ago
        People who were issued AI token credits.
- deleted 4mo ago
  [deleted]
- ramraj07 4mo ago
  Thats just a coding agent the "peopple" use via you, with extra steps.
frankfrank13 4mo ago
I think this is a really solid move. This gives OSS contributors a lot of flexibility. You could set the limit to 0, and manually add contributors. You could set it to 1-3 to allow people to get their foot in the door. But the de facto limit today is infinite, which is spammed. Imagine if GMail did this! If I don't whitelist or reply within `n` emails, youre done. I would KILL for that.
- SoftTalker 4mo ago
  I get a lot of emails that I want to get but never reply to. I would not want to have to remember to whitelist all of those.
  - frankfrank13 4mo ago
    Yeah fair, then you could set it higher, even 100. Or default it off.
- jasonpeacock 4mo ago
  HEY email service does something like that: https://www.hey.com/features/the-screener/ https://www.hey.com/features/the-screener/
- IshKebab 4mo ago
  > Imagine if GMail did this! It would be very annoying? Spammers can still spam one message, but now your friends can't email you twice. Awesome. This is a barely-better-than-nothing blunt tool.
cyanydeez 4mo ago
also, close all issues and open them as you plan to work on them.
deleted 4mo ago
[deleted]
esafak 4mo ago
We should have agents to triage PRs. Their "smarter bypass signals" is already implemented by Mitchell Hashimoto's Vouch system: https://github.com/mitchellh/vouch https://github.com/mitchellh/vouch
CodesInChaos 4mo ago
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).
- freedomben 4mo ago
  > 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
Unfunkyufo 4mo ago
I don't often give GitHub credit, because I work with it every day and I encounter something frustrating or broken nearly every day ending in "day", but kudos to them for working on addressing the some of the big problems. I also like the other features mentioned in the blog post. It won't make a difference to me and my daily work, but I'm glad that they are taking the criticisms seriously. Though I have to admit that I'm a bit conflicted about this. Part of me also wants more people to move off of GitHub to help break their monopoly on code on the web, but I also don't want the people making and maintaining open source to give up their projects due to burnout and slop spam.
deleted 4mo ago
[deleted]
trjordan 4mo ago
If you didn't take the time to write it, why should I take the time to read it? This is a band-aid. Maybe even a good band-aid, because it'll keep individual contributors from flooring the zone. But the core problem is Github's model that assumes code is worth reading. I'm much rather see the agent logs stapled to PRs. Make it easy to understand if there's a brain behind the suggested changes before engaging.
- cameldrv 4mo ago
  > If you didn't take the time to write it, why should I take the time to read it? This is the fundamental problem. You have to look at the equilibrium. When you submit a PR, you're asking for some of my time. I have to figure out if it's likely to be worth it for me. If you have a track record of producing useful software that I have merged before, you're putting your reputation at risk when you submit a new PR, so it's probably good. If you start sending AI slop, I'm going to downgrade your reputation. If you have no track record though, I'll probably at least take a glance since even if I'm not sure, at least you had to spend some time to write the code and put together the PR. Now that's not true. My guess is we're going to have to create some new systems for reputation, maybe bond posting, maybe "sponsored" PRs, where someone trusted vouches for it, etc. Incidentally, this doesn't just apply to PRs. It's emails, all kinds of other messages, reports, etc.
SaucyWrong 4mo ago
Somebodies are already making “loops” <facepalm> that will add the noise back. If PR isn’t merged in <time> close and open a new one, either the same one or a new one of higher priority. If <time> is set low enough, the noise still exists

101 points by ingve 4mo ago

mbaloch2136 4mo ago

[dead]

righthand 4mo ago

[flagged]

MeetingsBrowser 4mo ago
how so?
- righthand 4mo ago
  How else would it appear as a popular platform without bots everywhere? If there’s even any minor truth to dead internet theory then it extends to Github most certainly.

arjie 4mo ago

[flagged]

qazxcvbnmlp 4mo ago
Being able to submit an issue, description, test criteria along with a token budget would be pretty cool.
- arjie 4mo ago
  There's an amusing attempt at this here: https://clevercrow.io/ https://clevercrow.io/ It was on HN here: https://news.ycombinator.com/item?id=48621645 https://news.ycombinator.com/item?id=48621645
csiegert 4mo ago
There is also the solution of: No merge requests, just feature wishes and bug reports. All code is written solely by the maintainers (with the help of LLMs).
- parliament32 4mo ago
  Add a mechanism to donate tokens towards the maintainers' LLMs for a particular ticket and this whole class of problems will be resolved all at once.
  - wereHamster 4mo ago
    > Add a mechanism to donate tokens Or donate money. Crazy idea, eh?
    - toomuchtodo 4mo ago
      Some people have tokens but no money. Tokens, like Amazon gift cards and Tide detergent [1], are a form of currency in a way. If people have a currency equivalent they want to spend for your benefit, or the collective benefit, it makes sense (depending on level of effort) to enable them to do so. [1] How Tide Detergent Became a Drug Currency - https://news.ycombinator.com/item?id=5023204 https://news.ycombinator.com/item?id=5023204 - January 2013 (124 comments) (edit: maybe put AI tokens on stablecoin rails as value tokens? could be fun, could move them around instantly between participants on the value rails and could consume them programmatically, if someone implements this idea, buy me a beer!)
      - nozzlegear 4mo ago
        > Some people have tokens but no money. This sounds like a piece of worldbuilding from a Daniel Suarez novel. Who has tokens but no money?
        toomuchtodo 4mo ago
        People who were issued AI token credits.
deleted 4mo ago
[deleted]
ramraj07 4mo ago
Thats just a coding agent the "peopple" use via you, with extra steps.

frankfrank13 4mo ago

I think this is a really solid move. This gives OSS contributors a lot of flexibility. You could set the limit to 0, and manually add contributors. You could set it to 1-3 to allow people to get their foot in the door. But the de facto limit today is infinite, which is spammed. Imagine if GMail did this! If I don't whitelist or reply within `n` emails, youre done. I would KILL for that.

SoftTalker 4mo ago
I get a lot of emails that I want to get but never reply to. I would not want to have to remember to whitelist all of those.
- frankfrank13 4mo ago
  Yeah fair, then you could set it higher, even 100. Or default it off.
jasonpeacock 4mo ago
HEY email service does something like that: https://www.hey.com/features/the-screener/ https://www.hey.com/features/the-screener/
IshKebab 4mo ago
> Imagine if GMail did this! It would be very annoying? Spammers can still spam one message, but now your friends can't email you twice. Awesome. This is a barely-better-than-nothing blunt tool.

cyanydeez 4mo ago

also, close all issues and open them as you plan to work on them.

deleted 4mo ago

[deleted]

esafak 4mo ago

We should have agents to triage PRs. Their "smarter bypass signals" is already implemented by Mitchell Hashimoto's Vouch system: https://github.com/mitchellh/vouch https://github.com/mitchellh/vouch

CodesInChaos 4mo ago

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).

freedomben 4mo ago
> 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

Unfunkyufo 4mo ago

I don't often give GitHub credit, because I work with it every day and I encounter something frustrating or broken nearly every day ending in "day", but kudos to them for working on addressing the some of the big problems. I also like the other features mentioned in the blog post. It won't make a difference to me and my daily work, but I'm glad that they are taking the criticisms seriously. Though I have to admit that I'm a bit conflicted about this. Part of me also wants more people to move off of GitHub to help break their monopoly on code on the web, but I also don't want the people making and maintaining open source to give up their projects due to burnout and slop spam.

deleted 4mo ago

[deleted]

trjordan 4mo ago

If you didn't take the time to write it, why should I take the time to read it? This is a band-aid. Maybe even a good band-aid, because it'll keep individual contributors from flooring the zone. But the core problem is Github's model that assumes code is worth reading. I'm much rather see the agent logs stapled to PRs. Make it easy to understand if there's a brain behind the suggested changes before engaging.

cameldrv 4mo ago
> If you didn't take the time to write it, why should I take the time to read it? This is the fundamental problem. You have to look at the equilibrium. When you submit a PR, you're asking for some of my time. I have to figure out if it's likely to be worth it for me. If you have a track record of producing useful software that I have merged before, you're putting your reputation at risk when you submit a new PR, so it's probably good. If you start sending AI slop, I'm going to downgrade your reputation. If you have no track record though, I'll probably at least take a glance since even if I'm not sure, at least you had to spend some time to write the code and put together the PR. Now that's not true. My guess is we're going to have to create some new systems for reputation, maybe bond posting, maybe "sponsored" PRs, where someone trusted vouches for it, etc. Incidentally, this doesn't just apply to PRs. It's emails, all kinds of other messages, reports, etc.

SaucyWrong 4mo ago

Somebodies are already making “loops” <facepalm> that will add the noise back. If PR isn’t merged in <time> close and open a new one, either the same one or a new one of higher priority. If <time> is set low enough, the noise still exists