Julian, What I've been trying to illustrate multiple times now is that the incentives you are creating through this policy are not protecting you, but to the contrary make people think twice if they want to be honest with you and declare LLM use (however tiny that might have been, or not). You are even opening a game of "lets. see if I can use LLMs, not declare them, and have Julian review them without noticing." What kind of incentive is this? If all you want to be protected is a labeling, the policy should simply read: *We prefer contributions with non-trivial LLM assistance to be labeled LLM-assisted.* If you really wanted to you could even add a fairly neutral: It helps reviewers set expectations. This above wouldn't be enough for me though, as it does not say that we discourage drive-by-llm-contributions, and expect people to fully own their contributions. That however is completely irrelevant to you, as you don't want to interact with any of those, and as such will disregard them as soon as they are LLM-assisted labeled. And there is zero need for any form of judgement in either direction. You can at your discretion just not review PRs that have the LLM assisted label. If someone explicitly asks you to review a patch that has LLM-assisted, you can let them know that you'd prefer them to find another reviewer. Again, what I said before, there is *no right to review*. If you goal is to make sure people disclose their LLM use honestly, let's not have a policy that is outright stigmatizing people who use LLMs (because they did not share the "we strongly prefer hand crafted bytes" sentiment). If on the other hand you want GHC to be a project that actively pushes away (or makes people question if their contribution is welcome if they use LLMs -- even a hint of doubt is enough to discourage people, It's the UD part of FUD) a certain class of contributors with integrity, honesty but also occasional LLM use, write a policy that not only states LLM labeling, but also comes with a judgement call. Hence, and why I keep coming back to this, I don't see this as a compromise, even though I can understand why you see it as such. I see this as a judgement (and classification) of people, which is what I reject. What is most perplexing to me is, that you multiple times say you want more collaboration, but the incentives you seem to lay out, seem to contradict this. The incentives seem to push people away, make them question whether or not they are truly welcome or just tolerated. Maybe I'm fundamentally misunderstanding what you consider collaboration. To me this is fundamentally building trust between people. Throwing code over the wall, however conceived, is not that. Entering into a discussion, while providing contributions is closer to that. However putting up incentives to make contributors start out in the defensive is not that, insinuating distrust is not that, it all just leads to a corrupted interaction, not collaboration. If one party always has to assume they could at any point be accused of something, that they simply can not prove to be incorrect, we create a hostile environment. There is a reason why we generally follow in dubio pro reo and assume good-faith. This policy moves us from good-faith not outright to bad-faith, but into that direction; I object to _that_. Best, Moritz On Thu, 16 Jul 2026 at 12:00, Julian Ospald via ghc-devs < ghc-devs@haskell.org> wrote:
You clearly state that LLM usage for you is a signal of distrust.
Yes, I personally distrust patches with heavy LLM assistance and I do not believe people who say "but I know what I am doing".
This also means that I don't want to spend my free time interacting with such works. So who is protecting me?
The disclosure does that: it allows me to just walk away and have someone else look at the patch. And it definitely does protect you, because my negative bias won't be able to drive decisions (unlike in my own projects, where I outright reject such patches).
I'm confused why you don't see that this is literally the only compromise that is possible. I won't be contributing to projects, where people do not want to disclose their LLM use, even if it's "well, I use it all the time". That helps me set the expectations. _______________________________________________ ghc-devs mailing list -- ghc-devs@haskell.org To unsubscribe send an email to ghc-devs-leave@haskell.org