Thank you for the thoughtful response Christophe. We'll agree to disagree on the finer points but I respect your decision. On Thu, Feb 19, 2026, 3:52 PM Stas Boukarev <sta...@gm...> wrote: > And here I thought adding > Co-Authored-By: GNU Emacs 30.2 <no...@gn...> > as a gag. > > On Thu, Feb 19, 2026 at 11:48 PM Christophe Rhodes via Sbcl-devel > <sbc...@li...> wrote: > > > > Richard Westhaver <ric...@gm...> writes: > > > > > Figured it'd be worth starting a discussion on this - what do you guys > > > think about adding some language to the HACKING file (under Patch > > > Submissions) to guide future contributors? > > > > I'm not sure it's worth it (yet, if ever). I don't see a distinction in > > principle betwen LLM-assisted contributions and emacs-assisted > > contributions; in both cases the important part for me is being able to > > engage with the person contributing to ask questions like: "why?" and > > "why this way?" and questions of that sort. (And, again, I don't mind > > too much whether they use ispell or grammarly or an LLM to reply, but I > > my actions and judgment will be affected by the intellectual content of > > those replies). > > > > So whatever process leads to a person's (or an organization's) > > contribution, it stands in the context of the people proposing it, who > > need to be responsive, and (usually) very, very patient, because the > > bottleneck is rarely the pace of offered contributions (bug reports, > > patches, bug fixes) -- it's the time that maintainers can spend > > assessing them. > > > > Some of this list's older readers might remember USENET (or, more > > modernly, "Usenet"). I personally caught the tail end of its "mostly > > useful" phase, and learnt about Lisp there. But, from 1994, the commons > > of Usenet started to be tragedied, with the first unsolicited commercial > > e-mail, until the whole network collapsed under the noise. (I'm eliding > > a whole bunch of history; please don't take this as the definitive > > story.) The problem was a change in the cost-benefit tradeoffs: more > > people on Usenet, along with decreased bandwidth and access costs, meant > > both more eyeballs to view any messages, and lower costs to send them, > > with the (in retrospect) inevitable result. e-mail survives, just > > about, despite having the same structural problem, but it is radically > > different from its original conception, is very difficult to run an > > interoperable node in the network, and large amounts of resources go > > into making the typical e-mail signal tolerable despite the absurd > > volume of noise. > > > > The development of LLMs and their application to programming is, I > > think, a similar change: a change in the economics. We (more widely as > > free software developers) have already seen some of this: the advent and > > growth of programmes such as Google Summer of Code, security bug > > bounties, and the like lead to incentives to participants that might be > > surprising to those not participating: CVE requests, insistence on the > > importance of getting a pull request merged, that kind of thing. LLMs > > change the costs more than the benefits, but we would expect to see > > similar effects (for recent examples, the stories of curl and matplotlib > > in this week's Linux Weekly News are worth reading). > > > > But what can we do about it? We, just like USENET adminstrators, cannot > > control what people send, and trying to is essentially pointless. We > > can, though, continue to behave reasonably: assume good intent, and > > engage to the extent of our capacity with the people considering > > contributions, and insisting as far as we can on the correctness of what > > is merged -- while reminding people that anyone who thinks they can do a > > better job for themselves (and any community they engage) is free to > > take what is provided and build on it on their own terms. > > > > Christophe > > > > > > _______________________________________________ > > Sbcl-devel mailing list > > Sbc...@li... > > https://lists.sourceforge.net/lists/listinfo/sbcl-devel >