I think the author meant 'burnish' there, which is a clever way of showing they didn't use AI :-)

> 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 just being helpful.

This is weird though.

Obviously the best way to use AI to furnish your CV is to build your own project using AI.

Hi Neil, fun to see you on HN. I agree with your points and I you summarized it very well as "Ultimately, open source is built on trust".

AI is destroying trust in open source and many other areas and I think this will discourage teams from publishing their source code in the future.

On the other hand, personal connections are becoming even more important, which is unfair to the younger generation and people who don't live near tech hubs.

I’ve heard about similar issues with Hacktoberfest’s T-shirts back in 2020, but it was not as automated back then: https://news.ycombinator.com/item?id=24643894

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 made a tiny fix to Thrift codegen because some function could be much faster. These days I wouldn't bother. I'd just fork and leave upstream to be upstream.

I suspect many people are like me since it feels like a very normie position to take. That means that contributors are even more likely to be useful because both the drive-by genuine contributors have chosen otherwise and these contributors have increased.

It must be quite painful to be an open source maintainer right now. One wonders what to make of such projects in a future where a feature-list is a sufficient prompt.

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?

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