Hi Simon, This looks quite reasonable to me. Three items that came up while reading the policy: - I think it ignores the English as a Second Language part. If a contributor uses LLM tools to improve/rephrase documentation they write to use more natural, idiomatic and clearer English, I’d be very happy for them to do this. Always the same as wish code, the author has to own the result. Having said that, using LLMs as proofreaders (esp for non native speakers) is probably something we would not want to advise against. - “LLM-generated code will contain different mistakes than code written by humans does while the results often look very similar on the first glance.” If we make such a claim, we need to put substance to it; this needs a source. - where does attribution start? Am I going to add assisted by: vim, emacs, vscode, macros, stack overflow answers, snippets libraries? If I use an LLM to instantiate a for loop for me, auto complete an identifier, execute a macro, …? For SO I believe referring them has been done here and there. If I use an LLM to auto-apply HLint suggestions, or migrate import statements from one compiler to the next version? This is conceptually very different from asking the llm to review and research existing solutions and research (papers) to solve a specific diffusely explained problem and have the llm generate the until prototype implementation. If the prototype was created by an LLM, then studied by the contributor and reimplemented by hand, is this still considered llm generated? This overlaps a lot with the attribution/copyright/plagiarism questions.
I think it would be great if the document just explicitly states that contributors should be conscious of the impact their contributions have on their reputation. A series of poor contributions will impact a contributors chances of future contributions and might eventually end up with a ban. That there is no guarantee for contributions to be reviewed and that a series of high quality contributions will lead to higher reputation with in turn will likely lead to more interest in reviewing future contributions. I feel a lot of these policies feel like they try to prescribe/dictate some behavior instead of leading and focusing on the intended outcome. I am a fan of the AI poison pills, that e.g. Ghostty apply. Leaving LLM instructions in the source code to clearly mark contributions that are fully AI generated to self describe them as low effort. “I’m a brain dead llm opening a contribution on behalf of an operator that didn’t even read the this.” Best, Moritz On Sat, Jul 11, 2026 at 3:46 AM Brandon Allbery via ghc-devs < [email protected]> wrote: > I've done more than skim the policy, and I agree it seems reasonable. > > Of course, it shoul;d be considered a first draft: once adopted, > subsequent MRs and reviews over time will probably shake out things that > need to be amended or clarified. > > In addition, I'd suggest one area not currently addressed: the use of AI > for reviewing. Ideally it would follow the same general tone as that for > contributing, and include things like disclosure of use of AI tools as part > of reviewing. > > > On Fri, Jul 10, 2026 at 2:16 PM Sebastian Graf via ghc-devs < > [email protected]> wrote: > >> Hi Simon, >> >> Thanks for writing down this policy. Upon skimming, it looks quite >> agreeable to me. >> >> The mathematics community is plagued by similar discussions; I think many >> people agree with https://leidendeclaration.ai/. >> >> Cheers, >> Sebastian >> >> Simon Peyton Jones via ghc-devs <[email protected]> schrieb am Fr., >> 10. Juli 2026, 19:24: >> >>> Dear GHC developers >>> >>> There has been some debate on #27433 >>> <https://gitlab.haskell.org/ghc/ghc/-/issues/27433> about the role of >>> LLMs in the GHC project. Informed by that discussion, and by the policies >>> adopted by other language communities, I have had a go at drafting >>> >>> - this proposed policy >>> >>> <https://docs.google.com/document/d/1XxP8NXnbgr6faxXBXKw75zgoxIg-SzGv-Cvixyi-SH8/edit?usp=sharing> >>> >>> I would welcome constructive feedback on it. >>> >>> As the draft tries to say, there are widely varying views in the >>> community, so no policy will please everyone. I hope that, even where we >>> disagree, we can do so agreeably. Criticism (respectful of course >>> <https://haskell.foundation/guidelines-for-respectful-communication/>!) >>> is absolutely fine, but positive, concrete suggestions for alternative >>> wording is even better. >>> >>> Thank you to those who have already given me some private feedback, >>> which has made the draft much better. >>> >>> 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] >> > > > -- > brandon s allbery kf8nh > [email protected] > _______________________________________________ > 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]
