Am Mo., 19. Okt. 2026 um 07:48 Uhr schrieb Moritz Angermann <[email protected]>: > > Simon, > > We simply face the spam problem, due to the nature of the technology.
Could you please provide any evidence for this spam problem? My impression is that neither GHC nor any other Haskell project has seen a significant influx of spammy LLM-generated code contributions. So far, so good! However I'm concerned that by erecting further barriers against this hypothetical flood, we'd risk scaring away fresh contributors. > 4. I consider a contributor that opens a MR, and does not engage on IRC, > the mailing list or elsewhere with the community about their contribution > a rather poor contributor. As per the earlier (no right to review) rules, > their MR would just sit in the queue indefinitely. As such I expect we’d > automatically sweep stale MRs that haven’t found a reviewer after a > fixed period of time. I think a drive-by bug-fix can still be a valuable and acceptable contribution. And you never know if a one-time contributor might come back and become a long-time asset for the project. I also don't think that any contributors should be expected to engage on these communication channels. At least I'm not aware of any channels that would be sufficiently active and welcoming that I'd recommend them to a newcomer. Discourse is alright I think, but not very GHC-specific. Cheers, Simon > Again, nothing in this says anything about the use of LLMs. This only says > something about engagement in earnest and participation, as well as giving > some guidance on keeping the house tidy. What’s the value of a MR from > someone contributing not willing to engage with the community just to > disappear again? Unless there is a core maintainer that takes enough > interest in the contribution to take it over, merging it just leads to > liability > in the codebase. > > Just to reiterate: I do not believe that banning adversarial actors leads to a > hostile atmosphere. On the contrary I believe it leads to a cohesive > atmosphere > where everyone who wants to contribute feels welcome and valued. > > Attention is all you have. Spend it wisely. > > Best, > Moritz > > > On 19 Oct 2026, at 05:47, Simon Jakobi <[email protected]> wrote: > > > > Moritz, do you really think it's necessary to wave the ban hammer here? > > > >> We are basically facing the same issue we face with email spam. > > > > Could you point out an MR that you think is essentially spam? I'm sure > > that there have been several low-quality LLM-generated MRs by now > > (some of mine included), but I still believe that every contributor is > > trying to make GHC better. > > > > I'm not even against firmly rejecting low-quality contributions. But I > > believe that essentially all contributors are fundamentally > > well-meaning people who will respond to nudges when being nudged. And > > that's just what Andreas is achieving with his email and his reviews. > > > > All this talk of banning contributors or banning certain types of > > contributions is IMHO just creating a hostile atmosphere that is > > plainly off-putting for current and future contributors. > > > > I also think it's important to keep in mind that most of us are still > > figuring out how to best work with LLMs. Making mistakes is an > > important if not essential part of this learning experience. I'm > > grateful to Andreas that he's willing to point out these mistakes, and > > I think it's the right way to grow this community. > > > > Thanks! > > Simon > > > > > > > > > > > > > > > > > > And no, I still don’t believe there is a right to review. I still > > hold the position that anyone contributing will need to find a > > reviewer and that no one feel even remotely obliged to review MRs just > > because they show up on GitLab. > >> > >> And I would say that a poor PR is irrespective how it was conceived should > >> be rejected. If the wording is poorly written, superfluous or does not try > >> to hit a high bar, it’s not something anyone should entertain. Auto close. > >> If someone comes to IRC, the mailing list, an in person event, … and tries > >> to make their case for their contribution in an orderly manner, I’m sure > >> there will be plenty of folks who would like to help someone engaged to > >> contribute and support them in crafting a great contribution. > >> > >> Best, > >> Moritz > >> > >> On Thu, Oct 15, 2026 at 12:05 PM Julian Ospald via ghc-devs > >> <[email protected]> wrote: > >>> > >>> I'd argue that code or documentation that is so void of meaning to the > >>> human reader isn't just low quality, but also violates P3 of the AI > >>> policy. > >>> > >>> So you shouldn't really by asking these questions here, but simply reject > >>> such contributions. They're disrespectful. > >>> > >>> What I disagree with is that issue text and comments shall be excluded. > >>> Drafting a bug report or an elaborate feature request already constitutes > >>> a contribution that may be read by humans years later to understand > >>> context and decisions. Diluting this with low quality AI generated text > >>> is going to degrade the contribution experience significantly. > >>> > >>> Especially now that the industry is changing, juniors are struggling to > >>> find jobs and meaning in this field... we should be even more obsessed > >>> with the contribution experience than ever before, so that there will > >>> still be a future generation of GHC maintainers who cares as deeply about > >>> GHC as the current roster does. > >>> > >>> > >>> > >>> On October 14, 2026 11:08:51 AM UTC, Andreas Klebinger via ghc-devs > >>> <[email protected]> wrote: > >>>> Hello Devs, > >>>> > >>>> Given the use of AI has increased recently I think this deserves > >>>> discussion. > >>>> > >>>> There are certain texts that are, ultimately, transient, or read less > >>>> frequently as time moves on. > >>>> This broadly includes tickets, which generally become mostly irrelevant > >>>> once resolved. > >>>> > >>>> While reading AI tickets can be exhausting, I'm willing, within reason, > >>>> to accept them as a fact of live. > >>>> > >>>> But there are parts of the code base in which we have prose that is > >>>> written once and read > >>>> often. I'm primarily concerned with Notes, Commit messages, and to a > >>>> lesser degree code comments. > >>>> > >>>> I've noticed more people have been posting LLM generated bug fixes > >>>> (fine, it's policy) where > >>>> seemingly little work went into polishing texts other devs will read > >>>> many times. I consider this a problem. > >>>> > >>>> I think it's important for certain parts of the code base to be written > >>>> concisely. Something LLMs > >>>> are terrible at today, and even skills make it marginally better. This > >>>> is just a fact. > >>>> > >>>> I think especially with the release of Opus 5.5 this has become *more* > >>>> of an issue as the prose is > >>>> now only bad in a myriad ways that are not immediately obvious rather > >>>> than being obviously atrocious at a glance. > >>>> Which leads people to take it as-is without putting effort into writing > >>>> it by hand, or at least trimming it down after the fact. > >>>> > >>>> This is obviously bad for human consumers of these texts. But even if > >>>> you are "all in" on AI these texts > >>>> are also objectively garbage for future AI use as they are bloated with > >>>> irrelevant facts, meaningless past > >>>> history, repeating things obvious from context and generally wordy for > >>>> no benefit. > >>>> > >>>> They are simply bad. > >>>> > >>>> Is it fair to expect people to put in more effort into these? I think > >>>> yes. > >>>> > >>>> Notes are *the* way to understand the code base. And making them worse > >>>> permanently > >>>> degrades the ability of newcomers to understand the codebase. Similarly > >>>> commit messages > >>>> are hugely important to be able to determine when changes where > >>>> introduced, quickly find > >>>> ranges of commits to bisect for new bugs and many more regular > >>>> maintenance tasks. > >>>> > >>>> *My plan is to aggressively request improvement of prose during MR > >>>> review going forward.* > >>>> > >>>> Accepting bad prose is worse for maintainers because they have to read > >>>> texts three times to understand what is going on. > >>>> It's worse for agents because it fills context windows with irrelevant > >>>> facts and pointless trivia that poison their > >>>> reasoning ability. > >>>> > >>>> It's just worse, and it takes little effort to fix. > >>>> > >>>> But maybe I'm alone in feeling this way. If everyone else is happy to > >>>> read Opus text output all, or at least to have opus read opus > >>>> output all day long. Then I will surrender this fight and move to > >>>> another hill to die on. > >>>> > >>>> But if people are feeling similarly then please let me know and do > >>>> likewise. > >>>> > >>>> I don't think it's a big ask either. If you are prompting already just > >>>> type a draft in your commit message/note and let claude do > >>>> formatting/typo/alignment fixes. A sloppy text pushed through claude > >>>> will in most cases beat what any model today > >>>> will generate on it's own. Maybe this changes in 2 years. But it's not > >>>> changing today. > >>>> > >>>> It's not just a question of length. You can make a LLM generate shorter > >>>> texts with a skill file or otherwise. > >>>> But they are terrible at understanding what the tricky parts are, what > >>>> is worth highlighting, what can > >>>> be dropped because it is obvious from wider context. > >>>> > >>>> I think it's *easy* for every contributor who knows what is happening in > >>>> their patch to reach a reasonable standard. > >>>> But we have to ask them to do it and to set the expectation. And I hope > >>>> we can do so. > >>>> > >>>> Andreas, > >>>> > >>>> freshly back from reading some claude output. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>> _______________________________________________ > >>> 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] > _______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
