Hi Tom, For transparency upfront: assistive technology was used in parts of the conception and writing of this email. It has now taken more than two hours just to discuss, compose and edit this email alone in the hopes of being clear and easy to understand. I’m making this point specifically to underline that using assistive technology to me does not mean cheap and quick, but rather higher quality.
Thank you for your response and the clarifications. As I said before, I am agreeable with the revised policy Simon shared. I think it represents a compromise I can support. 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. 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. However, let us assume for the sake of argument that a majority really does prefer that LLMs are not used. I am still not convinced that the project should therefore add an explicit statement strongly preferring human-written contributions back into the policy. Please bear with me for a deliberately hyperbolic analogy. Suppose I distrust contributions developed on Windows. I might even have technical arguments for this position: - Windows commonly uses CRLF rather than LF line endings. - The GHC runtime system behaves substantially differently on Windows. - Windows has different filesystem and process semantics. - Code developed and tested primarily on Windows may therefore have a different set of failure modes from code developed on Linux. Based on these concerns I open a GitLab issue titled “Ban all Windows-developed contributions”. The issue attracts a number of people who also distrust code developed on Windows. Perhaps half of the people participating in the issue support a complete ban. Others don’t support a ban, but would still prefer that development happens on Linux. Eventually we reach a compromise: - Contributions developed on Windows are permitted. - Contributors are asked to disclose that the contribution was developed on Windows. - Reviewers who distrust Windows-developed code can use this information when deciding whether and how to review it. While I would not personally support such a policy, I can at least understand the argument. It is fundamentally about provenance. Now suppose someone argued that this compromise is missing its heart because it no longer says: > We strongly prefer code developed on Linux. This is where I think we cross an important line. There is a qualitative difference between providing provenance and the project itself attaching a value judgement to an otherwise acceptable way of contributing. Individual reviewers may distrust Windows-developed contributions. They are free to take that into account, to scrutinise them more closely, or to decline to review them. But stating a strong project-wide preference for Linux-developed code would elevate that distrust from an individual judgement into an institutional one. It would divide equally acceptable contributors into preferred and less-preferred classes solely based on their workflow. The policy would no longer merely say: > Please disclose information that reviewers may consider relevant. It would also say: > The project considers contributions produced through your workflow less > desirable. 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. To me, project policy does more than document current practice. It also communicates the kind of community we aspire to build and the incentive structures we create for future contributors. Personally, I would like those incentives to encourage openness, honesty, and collaboration. A contributor who openly discloses their workflow, takes responsibility for their contribution, responds thoughtfully to review, and ultimately produces high-quality work is, in my view, doing exactly what I hope our community encourages. 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. Best, Moritz
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
