3 ms·

Why not let them have the status boost? This isn't zero sum.

hypfer 1mo ago
> This isn't zero sum. True, it is actually negative sum, because fake merit erodes trust in real merit, as it makes it a lot harder to spot the latter.
- streetfighter64 1mo ago
  I think Goodhart's law applies really well here. When people make commits for the sake of having made a commit to some famous repo, the "merit" that a commit measures is already useless. Remember Hacktoberfest 2020, before LLMs were popular? https://news.ycombinator.com/item?id=24643894 https://news.ycombinator.com/item?id=24643894
  - brabel 1mo ago
    What merit was there to have anyway. Would the author accept the same changes from a human?? I am inclined to believe they would, I certainly would. Would you have attributed merit to someone just fixing typos? I mean it’s quite helpful. But I wouldn’t think a commit fixing typos ever attributed merit to a developer. So it’s hard to understand the problem with AI doing this. If it was a bot like dependabot but for fixing grammar errors would that be a problem? I assume no, hence the problem is entirely that the human author of the PR is being attributed nonexistent merit by people who should know better.
    - streetfighter64 1mo ago
      Well, as I mentioned there was already in 2020 the problem of (human-generated) slop commits causing unnecessary work for maintainers. The commit in itself might add some minuscule value to the project, but when you take into account the time it takes to check the commit and approve it, you're probably back at negative value again. Plus, there's the problem of people doing this in an adversarial way. How can you tell whether a random commit touching 100 files is the work of an enthusiastic beginner, or a malicious hacker that's hidden a subtle attack somewhere? Well, you need to spend your time carefully checking it. So it's way more pragmatic just to set up some automated filter to put all of this stuff in the bin. Oh and by the way: > I wouldn’t think a commit fixing typos ever attributed merit to a developer. The first sentences of the article in question: > Successful contributions to open source projects are a kind of currency. GitHub in particular encourages this in a number of ways: [...] Potential hiring managers often take note of this. Recruiters often find and screen candidates this way.
- tancop 1mo ago
  Why should a maintainer care about keeping PR count as a signal of developer status? A good quality contribution is a good quality contribution. You only have a responsibility to your own users, keeping out bad code from your repo while accepting as much good code as you can without getting overworked. You don't have to look after other people status games. If you judge first time contributors on accepted PRs that's as dumb as doing it based on their activity. It tells you nothing about quality. You're the stupid one for assuming all maintainers are as strict as you are.
  - pibaker 1mo ago
    It's less about being a maintainer and more about being on the SWE job market. Making it possible for any person to appear to be a prolific open source contributor even though his contributions are net negative for the projects he contributes to hurts the contributors who actually make improvements.
croes 1mo ago
Boost for what? That they can type a prompt? How do you distinguish those who know what they are doing from those who only can write a prompt and copy the result? Making the haystack bigger is a bad idea if you search the needle
- SmarsJerry 1mo ago
  Surprisingly prompting takes skill. The more you know about something the more precise you can be and the better AI actually works. I’ve found just saying “here is my bug/issue, fix this” is about the absolute worst way thing you could do, but give it a clear direction and precise step by step instructions and it will not only do well but sometimes blow your mind.
bulbar 1mo ago
Because every merge request and every merge comes with cost and (potential) more cost in the future. Linux lately received a lot of fixes for drivers nobody has cared about for ages. They decided to remove them. Maybe they should have done this earlier, I don't know, but that happened because every code change comes with cost down the line. For real contributers, this cost is much more limited and they have a higher probability of burden the cost down the line. Pure AI MRs are just rude, because it's just "here take this, don't really care what this is, but AI said it being good, I won't be around, so you will have to deal with this code after the merge and you better don't overlook anything, because I personally don't really know what I am doing, I only know how to have AI making something that looks convincing. Good luck fixing the bugs this change introduces".
selfhoster1312 1mo ago
Because letting sloperators near your codebase, even for a very minor obvious and correct change, may have long-term negative consequences for your project. It sends a signal to other sloperators to keep doing what they do, when we really need to send them a signal to get a life, learn a craft, and let Claude burn in hell.

> This isn't zero sum. True, it is actually negative sum, because fake merit erodes trust in real merit, as it makes it a lot harder to spot the latter.

streetfighter64 1mo ago
I think Goodhart's law applies really well here. When people make commits for the sake of having made a commit to some famous repo, the "merit" that a commit measures is already useless. Remember Hacktoberfest 2020, before LLMs were popular? https://news.ycombinator.com/item?id=24643894 https://news.ycombinator.com/item?id=24643894
- brabel 1mo ago
  What merit was there to have anyway. Would the author accept the same changes from a human?? I am inclined to believe they would, I certainly would. Would you have attributed merit to someone just fixing typos? I mean it’s quite helpful. But I wouldn’t think a commit fixing typos ever attributed merit to a developer. So it’s hard to understand the problem with AI doing this. If it was a bot like dependabot but for fixing grammar errors would that be a problem? I assume no, hence the problem is entirely that the human author of the PR is being attributed nonexistent merit by people who should know better.
  - streetfighter64 1mo ago
    Well, as I mentioned there was already in 2020 the problem of (human-generated) slop commits causing unnecessary work for maintainers. The commit in itself might add some minuscule value to the project, but when you take into account the time it takes to check the commit and approve it, you're probably back at negative value again. Plus, there's the problem of people doing this in an adversarial way. How can you tell whether a random commit touching 100 files is the work of an enthusiastic beginner, or a malicious hacker that's hidden a subtle attack somewhere? Well, you need to spend your time carefully checking it. So it's way more pragmatic just to set up some automated filter to put all of this stuff in the bin. Oh and by the way: > I wouldn’t think a commit fixing typos ever attributed merit to a developer. The first sentences of the article in question: > Successful contributions to open source projects are a kind of currency. GitHub in particular encourages this in a number of ways: [...] Potential hiring managers often take note of this. Recruiters often find and screen candidates this way.
tancop 1mo ago
Why should a maintainer care about keeping PR count as a signal of developer status? A good quality contribution is a good quality contribution. You only have a responsibility to your own users, keeping out bad code from your repo while accepting as much good code as you can without getting overworked. You don't have to look after other people status games. If you judge first time contributors on accepted PRs that's as dumb as doing it based on their activity. It tells you nothing about quality. You're the stupid one for assuming all maintainers are as strict as you are.
- pibaker 1mo ago
  It's less about being a maintainer and more about being on the SWE job market. Making it possible for any person to appear to be a prolific open source contributor even though his contributions are net negative for the projects he contributes to hurts the contributors who actually make improvements.

croes 1mo ago

Boost for what? That they can type a prompt? How do you distinguish those who know what they are doing from those who only can write a prompt and copy the result? Making the haystack bigger is a bad idea if you search the needle

SmarsJerry 1mo ago
Surprisingly prompting takes skill. The more you know about something the more precise you can be and the better AI actually works. I’ve found just saying “here is my bug/issue, fix this” is about the absolute worst way thing you could do, but give it a clear direction and precise step by step instructions and it will not only do well but sometimes blow your mind.

bulbar 1mo ago

Because every merge request and every merge comes with cost and (potential) more cost in the future. Linux lately received a lot of fixes for drivers nobody has cared about for ages. They decided to remove them. Maybe they should have done this earlier, I don't know, but that happened because every code change comes with cost down the line. For real contributers, this cost is much more limited and they have a higher probability of burden the cost down the line. Pure AI MRs are just rude, because it's just "here take this, don't really care what this is, but AI said it being good, I won't be around, so you will have to deal with this code after the merge and you better don't overlook anything, because I personally don't really know what I am doing, I only know how to have AI making something that looks convincing. Good luck fixing the bugs this change introduces".

selfhoster1312 1mo ago

Because letting sloperators near your codebase, even for a very minor obvious and correct change, may have long-term negative consequences for your project. It sends a signal to other sloperators to keep doing what they do, when we really need to send them a signal to get a life, learn a craft, and let Claude burn in hell.