Myself, I’d be more-inclined rather than less to take fixes from an LLM for spelling and grammar precisely because I’m reasonably confident that it’s easy to, at a glance, evaluate whether-or-not those fixes have, say, subtle security or correctness implications. Like, what I’m concerned about is more “has someone with an understanding of the code and the constraints on it considered how those constraints apply to it; an LLM won’t have a lot of relevant real-world knowledge on what needs to be done in this particular project”.

Even prior to LLM use, there have been projects that have automatic spellcheck or similar things run as part of the linting process on gettext strings. That’s an automated check from a much simpler system.

But setting that aside, it sounds like the fundamental issue is that recruiters are taking into consideration open-source contributions, and it’s easy to generate trivial open-source contributions like a spelling fix to get job-seeking credit.

I’ve personally submitted patches for spelling or grammar fixes over the years, just because when I’m using a piece of software, it stands out, and it’s an trivial fix to do; I don’t need to come up to speed on the coding conventions of the project or whatever. It does seem undesirable for projects not to take those.

considers

Maybe the answer is that there should be different lists of contributors. Like, one for non-code, one for major contributions, or something like that.

Or…maybe the problem will be resolved via technological mechanisms, if someone produces a system to analyze someone’s patches automatically for recruiters or other hiring people, so that there’s a less-crude mechanism than “did someone write a patch that got committed to a project at some point”.