Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Please stop flooding our projects with AI slop to furnish your CV

neilalexander.dev

Post reply on HN
Print view View original

31–40 of 162 posts

Re: Please stop flooding our projects with AI slop to furnish your CV

#31

Post by gunnarmorling »

I very much can relate, as I've also been receiving many of these drive-by PRs lately.

One big problem I have with them is that they take away time from project maintainers for reviewing and helping to get the PRs into shape, which then can't be spent on other, more important things. I feel like the "good first issue" GitHub label is specifically attracting these kinds of contributions.

It's not a black-or-white thing though, and you need to tell apart folks who produce slop PRs against any arbitrary repo, from folks using AI to contribute in a sensible way. We've tried to codify some rules in our contribution guide [1]:

- PRs from apparent bot accounts are closed - PRs from users who file large numbers against random repos are closed - You're welcome to use AI, but you need to stand behind your PR and be able to explain it

I'm sure we'll adjust those rules over time, but since we have instantiated them, it definitely has become easier to deal with AI PRs and handle them in an a relatively objective way. It absolutely means that sometimes a PR will be closed which could have been an improvement, but I think this is the right thing to do given the circumstances.

[1] https://github.com/hardwood-hq/hardwood/blob/main/CONTRIBUTI...

Re: Please stop flooding our projects with AI slop to furnish your CV

#33

Post by customguy »

dumpsterdiver wrote: post #5

> The changes were harmless and correct, but that did not make me feel better about accepting or merging them. So do you have the project’s best interest at heart or not? If you’re more concerned about the intent of a valid contribution than the content, why don’t you ask yourself where your intent is? You rejected a valid contribution based on unverified vibes about the person’s intent, instead of assuming they were…

Why not assume someone does have the best interest of their own project at heart? How do you get to question that out of the gate, while pretending automated grammar and spelling fixes to rack up PR counts are benevolent unless proven otherwise? Simply assume the person who made the thing you didn't make, who was the only person (or persons) on the planet to come up with that exact thing, knows what's best for that person (or persons). Just like you would handle your own stuff.

Re: Please stop flooding our projects with AI slop to furnish your CV

#35

Post by croes »

bwhiting2356 wrote: post #28
smooc wrote: post #20

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 is very or extremely limited. Why not have these PRs counted differently (by the platform), and/or colored differently in the timeline(s) thus made less visible or more clear?

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

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

Re: Please stop flooding our projects with AI slop to furnish your CV

#37

Post by hypfer »

GitHub flavored FOSS I believe works best for "corporate FOSS" projects and terrible for "FOSS as how it was conceived decades ago". Or rather I believe that it is engineered exactly for the former.

What it does well is coordination between corps, working in public (while on a corp payroll) and extracting some drive-by-PR value out of random third-parties.

The closer your project is to that shape, the better it works for you. The further it is away, the more pain you will feel.

This has nothing to do with AI slop. AI slop just turned up a few knobs that were already there.

Re: Please stop flooding our projects with AI slop to furnish your CV

#38

Post by zamadatix »

arjie wrote: post #18

This makes sense. Apart from the original thing, I no longer upstream anything. It just takes comparatively more effort than maintaining a private fork with my own idiosyncratic fix. This must mean that even small fixes that non-contributors would make in the past are just happening off the books, so to speak. e.g. I upstreamed a tiny fix to Thrift codegen because some function could be much faster. These days I woul…

I ran through exactly this thought process & LLM based resolution just 8 hours ago with a segfault compiling a project which likely doesn't care about the given platform combo much.

Re: Please stop flooding our projects with AI slop to furnish your CV

#39

Post by jspdown »

arjie wrote: post #18

This makes sense. Apart from the original thing, I no longer upstream anything. It just takes comparatively more effort than maintaining a private fork with my own idiosyncratic fix. This must mean that even small fixes that non-contributors would make in the past are just happening off the books, so to speak. e.g. I upstreamed a tiny fix to Thrift codegen because some function could be much faster. These days I woul…

How could it take less effort to maintain a fork? You have to merge the upstream in every week and fight endlessly on conflicts with your patches.

Re: Please stop flooding our projects with AI slop to furnish your CV

#40

Post by bulbar »

bwhiting2356 wrote: post #28
smooc wrote: post #20

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 is very or extremely limited. Why not have these PRs counted differently (by the platform), and/or colored differently in the timeline(s) thus made less visible or more clear?

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

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

Post reply on HN