I work in some fairly slop-tolerant environments, and even there I can't bear how bad LLMs currently fare at writing prose. The new rules make sense.
That said, for anyone working on projects where it doesn't matter as much, I have found some guidance is more effective than others. I would link to what I use, but it was generated by an LLM (heh) and is itself kind of sloppy. It's along the lines of: * Don't repeat yourself: no repetition of ideas across code, comments, commit messages, or pull requests. Rewording counts as repetition. * Comments do not describe *what changed* or the *bug that was fixed*. That's what commit messages are for. * Comments do not restate code. Code should be self-documenting. * Commit messages are subject-line only (no body) unless the reason for the change would be non-obvious to somebody reading the diff. Never summarize the diff. It's a bit more nuanced than that (e.g. explaining what comments *are* for, rather than just what they are *not*), but I recommend trying out some variation of that. On Mon, 19 Oct 2026 at 08:48, Moritz Angermann via ghc-devs < [email protected]> wrote: > Simon, > > We simply face the spam problem, due to the nature of the technology. It’s > trivial today to create not just one, or two MRs, but hundreds easily. For > trolls, bullies, or other folks just wanting to be a nuisance it’s utterly > trivial > to flood any service these days. The same as we have with email, you can > just send anyone an email, whether or not they want any (if they have an > email address). > > So yes, I think saying we are going to ban people who do not behave is > perfectly reasonable. Same reason why we ban people on IRC and elsewhere. > > Do not: I didn’t say ban anyone who uses AI, far from it. What I said is: > 1. Do not feel obligated to review PRs. > 2. Have contributors engage with the project if they want reviews. > 3. For contributors that show that they have no interest in good > faith contributions (drive by, poor quality, relay chat meat proxies), > ban them and ignore them. There is no point in letting poisonous folks > into a community. > 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. > > 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] >
_______________________________________________ ghc-devs mailing list -- [email protected] To unsubscribe send an email to [email protected]
