7 ms·

So the fixes are still fixes, but we (I am also a OSS maintainer) are unwilling to accept them as they boost the contributor’s status where we think the merit i

• hypfer 20d ago
  The whole idea of "counting PRs" as a vanity metric is flawed because vanity metrics are flawed. I don't think that there is a technical solution to be found here, as the problem is anything but technical. __ A hack/trap: Comment "Ah yes thanks a lot for the hint :)", then make the changes yourself. Then see how the person reacts to that. Hack the grifters. Hack the planet.
  • flyingshelf 20d ago
    My solution is to ask them for proof of work. Many of these disappear after opening a PR that they never tested. How can you claim to have fixed a visual issue without a screenshot? Insta-close.
  • __david__ 20d ago
    Or just pull the pr into your local git, git amend --reset-author, and then push it to master yourself.
    • stackghost 20d ago
      Merging commits/PRs without reading them is how you get a 2024 xz situation.
      • __david__ 20d ago
        I never suggested that you shouldn’t check the commit before merging!
      • yard2010 20d ago
        It still haunts me, that dot they slipped in, in one of the commits, every time I merge a PR
      • kodoman 20d ago
        Not just that how the maintainer was treated by the attacker which tells you something about the way people feel entitled to maintainers time and efforts for nothing even by people not looking to exploit the project. And the abuse after he received despite it being an easy mistake that the culture encourages people to make.
        • hypfer 20d ago
          > And the abuse after he received despite it being an easy mistake that the culture encourages people to make. I believe that that was in part simply people defending their reality. Because if it's not the maintainers fault, then why did it fail? What are the implications of that? What does it mean for me personally? Do I have to do something differently? Do I have to change my assumptions? People do not like these feelings. They want to simply push them away. The easiest way of doing so is blaming that guy and being done with the negative emotion. Most people do suck at this whole "being human" business.
  • initramfs 20d ago
    I have noticed a lot of my Github followers who are either newer students or just new to Github have an immaculate green board of commits on their profile page, but it's so over the top I only like the ones that have creative illustrations or just very limited edits. Some seem so automated that it's hard to know how much they actually work on it. Others even are programmed to follow accounts then drop off once the person doesn't reciprocate, which is technically better than them staying but also systematically checking what sticks (also Github should limit some of these automated follows).
• Arainach 20d ago
  Change is bad unless it's great. Unless the change is an obvious improvement, it has to be worth the time for the maintainers to spend attention reviewing it (and supporting the code forever, and all the rest). Even if these particular changes are "harmless" and easy to review, accepting them sets a precedent that encourages an unsustainable flood of AI-generated changes that will overwhelm the project.
  • brabel 20d ago
    That’s a totally unnecessary high bar you’re setting. Most change is mediocre (a tautology, I realize). I really don’t believe that you can think that fixing a bunch of spelling mistakes is not a small improvement. About setting a precedent: if you think like that you probably never accept any contributions at all, by humans or otherwise. Contributions by strangers have always been very minor things in general, things that the author cared enough about to make a pull request. In this case I don’t see the difference except for the fact that ai was used. If you just don’t accept ai at all , fine. But just be clear about it. In this case they are calling spelling correction slop. That’s not what slop means. Pretending human contributions were always “great” and nothing else would do is kind of ridiculous and shows a lack of experience in open source.
    • Arainach 20d ago
      It's not an unnecessarily high bar. Change is bad. It takes engineers time to understand and approve. It confuses users. Changes should be made for good reasons, not frivolously. Just because writing code is easier does not mean you should write more of it. It is more important than ever to carefully consider what you work on and what work you accept. The user says "this is just spelling corrections" but a maintainer - a volunteer - needs to read all the files and make sure it's harmless and doesn't introduce security vulnerabilities, change meanings, and so on. That's not free.
    • deleted 20d ago
      [deleted]
• bwhiting2356 20d ago
  Why not let them have the status boost? This isn't zero sum.
  • hypfer 20d 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 20d 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 20d 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 20d 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.
• Uptrenda 20d ago
  I think what you're saying is fair, tbh. Imagine you put in months or years into a project to make it a quality piece of work. It develops into something notable and you took all the risk. Then someone comes along to fix a spelling error with a pull request so their name effectively appears on the repo as a "contributor." And you just know right after its going on their resume as "contributed to [...]" or maybe if they're bold "software engineer working on [...]" which implies substantial investment. Then you're effectively sharing credit for YOUR work with someone who did nothing. That is rage inducing. ((Of course: it probably is just juniors trying their best in this horrible industry.)) On the other hand: lets be careful not to dismiss valid but inexperienced attempts to contribute. Having someone want to genuinely contribute to your software is incredibly generous. If someone seems like they're trying its better to give advice than act like a snob because its not good enough. Often pull requests only need small fixes to get in, anyway.
• 21asdffdsa12 20d ago
  These fixes, regularly destroy the architecture, accrue bloat for little gain, refuse to rewrite while demanding to rewrite- and many other such funny noises. Most code contribution by LLMs is garbage if you long-term care about the project. Look at closed source projects that ingest all this madness - windows with its seconds to open the explorer and other catastrophes.
• insane_dreamer 20d ago
  > So the fixes are still fixes, maybe, the maintainer would need to review them to determine that, and that can be time-consuming especially because LLMs tend to provide walls of sometimes dense text since the human submitting the PR (if there is one) couldn't be bothered to understand whether the change is a valid one (and therefore submit the change as their own work), why should the maintainer take on that work. if they wanted an LLM to find bugs in their code they could run it themselves with less work than sorting through LLM-generated PRs.