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.
Please stop flooding our projects with AI slop to furnish your CV
81–90 of 162 posts
Re: Please stop flooding our projects with AI slop to furnish your CV
#82So 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?
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.
Re: Please stop flooding our projects with AI slop to furnish your CV
#83IMHO, the days when open source contributions are often positive signal for hiring are long gone. Actually, if I see someone doing open source like it's a performative career checkbox, that will not be positive signal, and could easily be negative. I understand that people will do what they need to do to get a job, but that pragmatic career checkboxing itself isn't positive. I will have to look for positive signal el…
Re: Please stop flooding our projects with AI slop to furnish your CV
#84So 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?
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.
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.
Re: Please stop flooding our projects with AI slop to furnish your CV
#85Re: Please stop flooding our projects with AI slop to furnish your CV
#86Earlier quoted context omitted.
Or just pull the pr into your local git, git amend --reset-author, and then push it to master yourself.
Merging commits/PRs without reading them is how you get a 2024 xz situation.
Re: Please stop flooding our projects with AI slop to furnish your CV
#87I've submitted PRs for typos in the (pre-LLM) past, not to boost my GH profile, but because I thought I was being helpful. Guess I was wrong...
Re: Please stop flooding our projects with AI slop to furnish your CV
#88Do recruiters actually care about your open source contributions? Especially now when only LLMs read CVs and match them against strict criteria, I doubt there are many companies that actually care about your work outside of work, in fact they might care in opposite direction - thinking that you'll be distracted from work
Re: Please stop flooding our projects with AI slop to furnish your CV
#89This 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.
By the way, interesting person to have 512 IPv4s (and two /44s? Aren't those enormous?). Root-level http intentionally user/pass gated on your site? I was curious to see.
Re: Please stop flooding our projects with AI slop to furnish your CV
#90> The changes were harmless and correct,
> I closed all three PRs without comment.
What is this article? I get real ‘AI slop PRs’ are nightmares - but I take that to mean the wave of AI generated PRs that read convincingly but are in the end bullshit.
But your example is NOT that. The unreasonable counter to your point: don’t make spelling mistakes in the first place? Or switch off PRs if you don’t want things corrected?