Humans are bad at writing secure code, and GNOME developers are no exception. GNOME is primarily written using unsafe programming languages where simple mistakes in our code lead to devastating consequences for our users, and we make these mistakes all the time. No matter how much we try, GNOME developers will fail write secure code...
I’m trying to contribute to clippy now and the situation looks bleak for maintainers.
Previously the signal was: could make a PR. Things like docs and tests were “wow this person is good” and a description that linked to the issue it closes and actually explained that it did was a 10/10.
Mantainers have always relied on signals to determine where to invest their limited time. When they do invest it, it was clear their empathy is met and reciprocated. Now those signals are gone and there’s not a good way to distinguish between “I spent days and hours meticulously promoting fans getting reviews and iterating combined with my own human iteration” and “told Claude to get me internet points to boost my resume in a Ralph loop”. There’s not even a guarantee the person on the other side is in fact a person.
The rust/clippy policy is very thoughtful and clearly spells out how to use LLMs with empathy for the eventual maintainer/reviewer. I ran afoul of it by some degrees and even though I’m in the “meticulous code” camp of LLM users cannot genuinely say code produced by the machine isn’t in the final product. I can though, and will. So closed it and will rewrite it.
I think LLM scanning is good. But LLM issues and PRs are not. We need a human who has the skills and empathy for reviewers to make it easy enough for them. The challenge has never been the work, the challenge has always been doing the work in a way that is reviewable, maintainable, and sustainable. We need to find community standards and guidelines to reflect that reality.
I think the empathy gap is challenging here. At this point, people have a different sense of how important code is. Some people have gotten really used to shipping products quickly. Friction is anathema to them.
For some work projects, I found myself writing detailed replies to some PRs only to have them answered immediately. That indicated to me that the person didn’t even read what I wrote. They just told Claude, “hey, there is a reply. Go handle it.”
I fear that approaching an overwhelming onslaught of automated contributions with empathy is just fuel for burn out.
I’m trying to contribute to clippy now and the situation looks bleak for maintainers.
Previously the signal was: could make a PR. Things like docs and tests were “wow this person is good” and a description that linked to the issue it closes and actually explained that it did was a 10/10.
Mantainers have always relied on signals to determine where to invest their limited time. When they do invest it, it was clear their empathy is met and reciprocated. Now those signals are gone and there’s not a good way to distinguish between “I spent days and hours meticulously promoting fans getting reviews and iterating combined with my own human iteration” and “told Claude to get me internet points to boost my resume in a Ralph loop”. There’s not even a guarantee the person on the other side is in fact a person.
The rust/clippy policy is very thoughtful and clearly spells out how to use LLMs with empathy for the eventual maintainer/reviewer. I ran afoul of it by some degrees and even though I’m in the “meticulous code” camp of LLM users cannot genuinely say code produced by the machine isn’t in the final product. I can though, and will. So closed it and will rewrite it.
I think LLM scanning is good. But LLM issues and PRs are not. We need a human who has the skills and empathy for reviewers to make it easy enough for them. The challenge has never been the work, the challenge has always been doing the work in a way that is reviewable, maintainable, and sustainable. We need to find community standards and guidelines to reflect that reality.
score 1 · canonical
I think the empathy gap is challenging here. At this point, people have a different sense of how important code is. Some people have gotten really used to shipping products quickly. Friction is anathema to them.
For some work projects, I found myself writing detailed replies to some PRs only to have them answered immediately. That indicated to me that the person didn’t even read what I wrote. They just told Claude, “hey, there is a reply. Go handle it.”
I fear that approaching an overwhelming onslaught of automated contributions with empathy is just fuel for burn out.
score 1 · canonical
Lots of these effort signals is something I’ve been queue for a while, eg see https://blog.happyfellow.dev/simulacrum-of-knowledge-work/
score 1 · canonical