Re: [PATCH] Documentation: document expectations around AI use

[Valentin Gagarin <valentin@gagarin.work>]

I like the nature of the argument, but from my own experience would 
suggest a different policy: don't submit LLM output.

One piece of rationale behind that is in essence the same as yours, 
something along the lines of "contributors are assumed to understand 
what they're writing".  But even that still feels vague, because of 
course one can understand a given LLM output and package that as a 
contribution.  Therefore I would like to sharpen that line of reasoning 
before committing to that.

The other piece of rationale has more weight for me: you wouldn't submit 
search engine output verbatim either.  LLM output is qualitatively the 
same as generated code, plus randomness.  Why would you check that into 
version control?  That would also still need a constructive formulation 
for people further from this bubble to make sense immediately, but do 
you see what I'm getting at?

Certainly we should emphasize the part that sending LLM output 
needlessly shifts more burden onto reviewers, and the threshold to 
consider that spam is very easy to cross.

This deliberately leaves open which tools you use and how you use them 
to arrive at your contributions.  Another thing also worth mentioning is 
that the contributor may be liable for all the legal implications of 
labeling LLM output as one's own contribution.  What if a particular 
piece turns out to violate copyright?  For that reason, maintainers 
should therefore not let into their codebase what is marked as LLM 
output, and otherwise take authorship claims for granted.

But again, I agree with the spirit of your proposal, which to me reads 
like that the project's communication channels are for people, period. 
Still figuring out how to state it so that spirit gets across despite 
cultural differences.  Maybe this would even allow us to bypass the LLM 
debate in documentation altogether, ideally without having to re-explain 
why e.g. checking in any sort of machine output is not a good idea in 
general.

Thinking about it a bit more, the underlying theme is actually that of 
engineering, contribution, and communication culture.  It's easy to get 
along with people who happen to share it, but it's a lot of work for 
both sides when implicit assumptions don't match.  We may be even better 
served than by just policing LLM use if we state at least some of the 
core assumptions which drive the project, provide some guidance for how 
to soak up that culture, and ideally explicitly state positive examples. 
  That may substantially reduce the need to play catch-up with instances 
of the same phenomenon.