Thanks for taking the time to write, Simon. I have updated my draft
- Under "A human conversation", mention that in human interactions it's fine to include LLM quotes.. That said, and speaking for myself at least, if I'm conversing with a human, say Robert, I really do want it to be Robert not Claude. If written interaction is hard, I'd be happy to hop on a call with Robert, or communicate in some other way that allows us to communicate well. - Under (P1) bring out your point about draft MRs. (I suggest explicitly saying "Not ready for review" in the Description.) - Under (P2) bring out your point about tickets having looser criteria. I also added a para about asking for help. I intended the tenor of the document to be positive: working in partnership with other members of the Haskell community, and developing a code base of which we can be proud. About LLMs I know that not everyone will agree, and I think we need to find a way to disagree agreeably, without knee-jerk reactions of fear or anger, just with a recognition that other, equally thoughtful, people may hold different views to ours. For this reason the policy deliberately neither says "LLM bad" nor "LLM good", although I know that members of our community hold both views. Rather it focuses on outcomes: the effect on reviewers, on our human conversations, and on the code base. That may satisfy no one fully, but I hope it may be at least acceptable to most. Instead of trying to discourage contributions that involve LLMs, I think > this project should rather try to welcome creative use of LLMs for the > benefit of this project and all Haskell users. My intent was NOT to discourage contributions that *involve *LLMs. The intent (for the reasons above) is to be neutral on "involvement". The draft does indeed express a strong preference that code and documentation are written by you -- but it's only a strong preference. If you forensically review and hone every line, that's fine: you are taking full responsibility. What no one wants (I'm sure including you) is pages of machine-generated code or documentation that no one understands. thanks again Simon On Tue, 14 Jul 2026 at 15:42, Simon Jakobi via ghc-devs < [email protected]> wrote: > Hi Simon, > > here are my comments on the policy document: > > > In particular, you must not use AI-generated text in a direct > conversation with a human reviewer. > > I think this is too restrictive. A contributor may easily reach the limits > of their understanding during a code review, and I think it's ok to resort > to using an LLM then. I think it's fair to require that they clearly mark > the LLM-generated part of their response though. > > > P1: Write MRs that are easy to review > > I fully agree with this, and apologize that some of my MRs have not been > easy to review! I do want to point out though that MRs marked as "Draft" > should not be held to the same standards as a "ready" / non-draft MR. I > frequently open draft MRs mainly to get the CI results. Sometimes I still > get detailed reviews on these MRs, and then feel sorry that a reviewer > wasted their time on this. > > > P2: Full responsibility > > > You must understand, and be able to explain, every line of code, and > every sentence of documentation. Every line! > > I think that's a good goal, but even for MRs, maybe too strict a > requirement. Where do you draw the line? Is the contributor expected to > understand every (pre-existing) function they used? To what extent? > Strictness and performance characteristics too? > > For bug reports, I think GHC should be more lenient, and instead require > that LLM use is clearly signalled. > > > P3: Strong preference for human authorship > > > We strongly prefer human-written code > > I understand that it's "good exercise" to write code by hand. > > But I've always been pretty bad and extremely slow to write code. And now > that recent models have become so good at producing code, I was relieved > that I can now contribute without being so limited by my code-writing > skills. I already realize that some core contributors have much disdain for > LLM-generated code. If the GHC project decides to devalue contributions of > LLM-generated code with this language, I think this will reduce my > motivation to contribute. > > > Writing it yourself forces you to think about every line; and it imposes > a cost on you if you write 1000 lines instead of 100. > > IMHO contributing to GHC is already quite onerous and "costly", especially > for newcomers. Just think of the flaky CI system and recent GitLab > performance. Instead of trying to impose additional costs on contributors, > I think it would be better to try to reduce the cost of reviewing and > maintenance! For example, I think GHC should try using LLMs for > "first-line" code review. LLMs are already very capable at debugging. How > about investing in fuzzing or better automated testing, so bugs are > discovered before they make it into a release? > > > We strongly prefer human-written documentation. > > Documentation generated by recentish models like Claude Opus 4.8 has > indeed been quite bad. Claude Fable 5 is already much better at this. > > I think the main incentive resulting from this policy is to include _less_ > documentation in contributions. In a world where LLMs are very capable of > making sense of large code bases, maybe that's not much of a drawback. > > --- > > Overall, I feel that much of the recent discussion about LLMs in GHC and > Haskell has been driven by fear and anger. I think many Haskellers are very > proud of their skill to produce high-quality code, and as LLMs get better > and better at this, this skill is becoming "less special". > > Instead of trying to discourage contributions that involve LLMs, I think > this project should rather try to welcome creative use of LLMs for the > benefit of this project and all Haskell users. > > Sorry for the bad wording here and there. I did not use an LLM to write > these comments, and it took me an embarrassingly long time. > > Cheers, > Simon > > _______________________________________________ > ghc-devs mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
