Please stop flooding our projects with AI slop to furnish your CV
64 points by lr0
64 points by lr0
Honestly, I've always considered cleaning up minor grammatical errors like the equivalent of picking up a random bit of trash as you're walking around. I probably won't go too much out of my way to do so, but if it's on my way I'll pick it up and throw it in the bin. When I'm reading through some docs, if I find an obvious error I use the web interface and send a quick PR to fix it unless the project requires anything more involved, in which case I give up. I've also had a similar experience where I ended up making multiple sequential fixes because I encountered more errors as I kept reading and I was doing the edits in real time.
I'd do the same thing on Wikipedia if I encountered a minor grammatical error, without thinking about it. When you see the candy wrapper next to the trash can it takes 3 seconds to pick up and throw it away, and everyone benefits.
If protecting the sanctity of your contributor list is so important, then maybe it would make sense to advocate for GitHub to filter out such minor contributions from appearing in the list, or to tag them as such in some way. Maybe GitHub can provide a mechanism to filter out those PRs and automatically close them, if they are indeed burdensome. I think in general it is desirable to encourage pro-social behavior and this was always one of the major benefits of Wiki-style collaborative editing. Given that it is desirable to have well-written docs, maybe it is worth exploring the solution space for alternative solutions that build towards better outcomes, especially as we adapt towards a world where AI-driven tools are the norm.
I've not done a poll, but I strongly suspect there's two groups of people here with a very small space between them:
There's a difference between "hey friend, just noticed a small error, while using this, let me fix that!" and "I'm going to crawl projects to find minor pedantic things to correct that no one will benefit from to boost my CV". One is a collaborative effort and being part of a community. The other is abusing that community like your personal wankdoll.
It's debatable whether these "fixes" are even correct, because personally I consider "an URL" and "a URL" both fine. There is no one standard spelling – only conventions – and we're not writing for the New York Times where we have to follow their editorial guidelines. Regardless, 384 people got that notification to fix some comment on an unexported function which doesn't measurably improve anything just so that some rando can spunk all over their CV.
Beyond typos, almost all of these PRs that I've received have ranged from "bad" to "complete garbage". Often obviously bad or obviously complete garbage if you spent more than 30 seconds looking at it. It's almost always from "opened 385 PRs in 251 repository" people. The end result it's just noise for exceedingly minor benefit at best, and often no benefit at all.
Wikipedia also suffers from this by the way, although the dynamics are a bit different and its mostly people using bots to (sometimes aggressively) "correct" pet peeves. This has also been somewhat controversial for a long time.
I consider "an URL" and "a URL" both fine.
I’m not sure if I’ve ever come across someone using the /ˈɜːrl/ (same as “earl”) pronunciation in real life, though I feel like I’ve heard of it. (And unless you’re pronouncing it that way, “an URL” is wrong.) Comparing “a URL” and “an URL” in Google Ngrams Viewer shows “a URL” to be vastly more popular, around 25× so.
It’s sufficiently stacked that I’d be willing to consider /ˈɜːrl/ a mispronunciation and consequently “an URL” a misspelling. Though 4% is a good deal closer than I imagined.
(Dialect and accent differences are fun. 1 Kings 10:29 in the KJV: “an horse for an hundred and fifty [shekels of silver]”. Not sure if anyone still has a silent aitch in horse or hundred. I think it is appropriate in reading that aloud to drop the n; “a” and “an” are the same word, just context-pronunciation-dependent spellings, the only case in the English language I think, though “the” has a context-pronunciation-dependent pronunciation. A more current example: if you write “an herb”, I will guess that you’re American, because most of the world would write “a herb”.)
This is definitely the kind of thing that I could easily have come across, been bothered by, investigated, … found that “an URL” is more common than I realised, and begrudgingly decided not to submit a patch for after all, even though I’ll still consider it wrong. But more unequivocal typos and such, those I have historically often submitted small patches for when I find them.
Incidentally, it’s not necessarily 384 people that got the notification; a good fraction of them may only be watching releases.
I don't think the author is necessarily complaining about people like you. I have a very minor open source project (niche, think 100 users), and I get PR requests from these people who just spam every project out there, with contributions that have absolutely no value.
They aren't being good Samaritans and picking up trash as they walk by. I guess the best parallel would be to bring a camera crew in to film how much of a good person you are, and broadcast your act of picking up trash on TV.
Honestly, I've always considered cleaning up minor grammatical errors like the equivalent of picking up a random bit of trash as you're walking around. I probably won't go too much out of my way to do so, but if it's on my way I'll pick it up and throw it in the bin.
This reads like you’re a raccoon living by a trash can, haha. Good example though.
I'd do the same thing on Wikipedia if I encountered a minor grammatical error, without thinking about it. When you see the candy wrapper next to the trash can it takes 3 seconds to pick up and throw it away, and everyone benefits.
Good on you! I also try to do this for subjects in my field, especially when they’re wildly wrong.
I've done that as well. English is not my first language so a typo or missing word can get me reading the thing over and over until I notice it's not a me problem.
That said, I think the maintainers time was always so scarce on Rails that the team didn't allow these types of PRs.
The main problem is that GitHub does not give project owners enough tools to manage things.
One "solution" to this problem is to allow maintainers to take a PR independently of the author getting credit. If the author may not get credit, this kind of burnishing disappears but people like you can "pick up trash" anyway.
And responsible project owners will still let the authorship credit assign to genuine PRs.
Honestly, I've always considered cleaning up minor grammatical errors like the equivalent of picking up a random bit of trash as you're walking around.
I do this too, to the point where I've written about it (that blog post long predates LLMs and I'm not sure it holds up in the LLM era, please don't judge it too harshly!). But, given the current LLMs-in-open-source climate, I only really feel comfortable doing so because I have an established track record in open source already, which hopefully signals that I'm not just spamming with LLMs. (I also usually don't bother writing a description, because the value is obvious from the title alone. Ironically, I used to wonder if I should write one, but now I wonder if "no description" also signals a non-LLM contribution.)
I also think it's worth noting that you and I are talking about updating documentation that we ourselves are reading, whereas the blog post is talking about the LLMs having updated (AFAIUI) code comments.
Perhaps ironically, I would suggest that the author of this headline meant burnish, not furnish.
I won't send a PR, though.
Furnish feels distinctly more appropriate than burnish to me (though I wouldn’t quite say burnish was wrong).
I've had several pull requests lately where the fix is correct and the description sounds plausible, but the author doesn't seem to know the codebase. I wish GitHub let maintainers require some activity in the repository before a first-time contributor can open a pull request. Even requiring an issue first would filter out a lot of drive-by submissions.
I mean I do agree with it, but I think the wording is not the greatest in the article. I've determined this patch is correct and harmless, but I'm rejecting it because I suspect you generated it to make your GitHub profile look better just doesn't give great vibes.
The fact clankers are taking those easy to fix, good first issue PRs is really sad to me. Fixing some small typos is the first thing I did when I first got into open source, opening that “fix typo” PR was what helped me work the courage to start doing more, and now I do open source for a living
I'll make a counter argument.
Previously, when contributors sent code change requests, they would sometimes spend a bunch of time working on it. Ideally, they would send a ticket first so the maintainer and contributor could discuss. However, now with AI, code changes are much easier to generate -- often with little human intervention. Prior to AI, I would have anxiety around rejecting contributions when people spent a considerable amount of time on it. Now I feel zero guilt when I close PRs and often receive very little pushback.
Also, sometimes these contributions are legitimately solid which gives me a cheap "prototype" to read, investigate, and potentially rewrite. I have zero issue with AI contributions or making major rewrites on top of the commits.
For the majority of projects, I don't understand the arguments around reputational requirements. For massively popular projects, fine, there's a scale issue there. But being on GH is a asking for slop, consider it a social contract at this point.
and potentially rewrite
Please don't do this. I've written off entire projects from further contribution because of that behavior.
Contributors are putting effort into learning your codebase and writing code for it. If you simply cut them out and rewrite the code they sent, it invalidates all of their effort. Better to just report bugs or request features, since the maintainers will just do it themselves anyway, and probably do it better since they have all the context.
You should engage with them instead in order to get the code into the shape you want so that you can merge it with full authorship.
Yet another reason to move off GitHub.