Re: Official policy on LLM-assisted contributions

Richard Westhaver <[email protected]> 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