Hi Moritz, Many of your paragraphs here seem to reiterate arguments you've made previously. Additionally, you don't seem to have assimilated any of the points of earlier responses. For example, several days ago you equated pro- and anti-LLM positions with developers debating using Emacs vs. Vim. Several people responded with why that wasn't a helpful analogy for them, and yet in this email you're equating the debate with Linux vs. Windows, seeming not to take on board any of their points. At this point I think we should focus only on finding how to "disagree agreeably." I've responded to a few of your points inline:
On 07/25/2026 4:35 AM CEST Moritz Angermann <moritz.angermann@gmail.com> wrote:
As I said before, I am agreeable with the revised policy Simon shared. I think it represents a compromise I can support.
Unfortunately it does not represent a compromise that I and many others can. Specifically, it seems slanted in favor of LLM users doing whatever they like, provided they disclose their LLM usage.
There is, however, one part of your response that I still struggle with.
“human-written” means, well, written by a human. I think we probably have a philosophical disagreement here about what writing or authorship is. To me, understanding, judgement, selection, revision, adoption, and taking responsibility for the result are more important than whether I personally produced every character of the final representation. I don’t think we will necessarily resolve that disagreement here, though. More importantly, the revised policy does not require us to. It focuses on understanding, responsibility, quality, and disclosure, which I find quite reasonable.
Please recognize, though, that what you find quite reasonable is exactly the part that I and others disagree with. We haven't found a compromise position by adopting criteria that ignores usage of LLM (other than disclosure).
On this point:
acknowledging that a majority prefer LLMs not to be used. I’m not convinced this conclusion follows from the GitLab discussion itself. The issue was titled “Ban all LLM contributions”. A discussion framed in this way seems inherently self-selecting to me. People who strongly oppose LLM use have an obvious reason to participate. People who use assistive technology, are indifferent to its use, or simply consider the proposed ban unlikely to succeed may just ignore the issue and let those interested in it discuss it. To be clear: I am _not_ claiming that the opposite conclusion follows. I do not know what the majority of GHC contributors thinks about LLM use. My point is only that I don’t think we can infer the preference of the wider contributor community from the people who chose to participate in this particular issue.
This seems like motivated reasoning. Why should we doubt that pro-LLM users would be at least as likely to vote on an issue that would ban their preferred workflow? Occam's razor is that around 50% of people who care about the issue, want to ban LLM usage entirely. You will notice, by the way, that my name is not among those voting to ban usage. This is because I feel GHC needs to move forward with a compromise that doesn't leave people feeling totally left out. Unfortunately, the current draft does this in my view, in the other direction.
I would find that objectionable even if a majority of participants in the “Ban all Windows-developed contributions” issue supported it. This is how I see the proposed preference for human-written contributions as well. I don’t object to the present policy stating expectations around responsibility, understanding, quality, and disclosure. As mentioned above, I am agreeable with the revised policy.
What I object to is adding an institutional ranking of otherwise acceptable workflows back into it.
One reason I care about this distinction is that I want GHC to remain an open and welcoming project for contributors.
You seem not to recognize that we cannot have our cake and eat it too. For each person who'd say "Yippee! I can use LLMs!" there is another person who says "Oh no, discussion on important issues is LLM-generated. I don't want to read that." I'm seeking to find a compromise position here, but for that to work, both sides need to recognize that there is no free lunch: no solution that will be maximally welcoming for all people of all stripes.
By contrast, explicitly declaring one otherwise acceptable workflow to be _preferred_ over another risks sending a different signal. Even if that is not the intention, it creates the impression that some contributors are viewed as inherently more desirable than others despite meeting the same standards of quality and responsibility. That seems misaligned with the kind of welcoming, collaborative, and trust-based project I would like GHC to be. Perhaps some contributors distrust LLM-assisted code. The present disclosure requirement gives them the information necessary to act on that distrust. I don’t think the project additionally needs to adopt that distrust as its own stated preference.
Another "no free lunch" situation: embedded in your view here ("The present disclosure requirement gives them the information necessary to act on that distrust") is that a person who dislikes LLM contributions can remain unaffected by them simply by not reading LLM code or documentation. Your proposal (everybody develops how they please; people who don't like it shouldn't participate) sidelines people and excludes them from meaningful discussion and information about GHC's future. And of course, they'll end up reading LLM-generated code and/or documentation if it's merged in. As soon as you recognize there's a balancing act here, I think you'll understand more where many of us are coming from. Thanks, Tom