> the removal of a statement of preference for human-written code takes the heart out of this document. It would cause me to withdraw my support
This sentence disappeared from Simon’s v2 draft, but from your replies it seems clear that you consider it essential.
That made me realize something.
Perhaps part of our disagreement stems from the fact that we’ve been using terms such as “human-written” without ever defining them. These are the definitions I have been implicitly using throughout this discussion.
Human-written: Each and every substantive character of the final text was manually composed by a human. No assistive tooling was used to produce the substantive wording itself.
Machine-written: Each and every substantive character of the final text was produced by a machine without meaningful human intervention. This is, to me, the diametric opposite of human-written.
Human-delegated: A human deliberately delegates the production of some or all of the substantive text to a machine.
Human-guided: A human iteratively guides the production by providing prompts, constraints, corrections, examples, and feedback.
Human-supervised: A human continuously evaluates, accepts, rejects, or redirects the machine’s output while it is being produced.
Human-edited: A human substantially modifies machine-produced text after generation before adopting it.
Human-authored: A human exercises judgement over, understands, selects, revises, adopts, and ultimately takes responsibility for the resulting work, regardless of how individual parts of it were initially produced.
I don’t expect everyone to agree with these definitions. They are simply the definitions I have been implicitly reasoning from throughout this discussion.
I also don’t think the intermediate terms form a strict ordering. Rather, they describe different ways in which humans and machines can collaborate during the production of text. What I do think forms a spectrum are the two endpoints: fully human-written and fully machine-written. Human-authored, to me, is orthogonal to that spectrum.
One reason I think these distinctions matter is that I don’t believe I have ever argued in favour of machine-written contributions. Throughout this discussion I have been arguing about workflows that remain under human judgement, supervision, direction, and ultimately responsibility.
Conversely, I have consistently interpreted human-written literally. That is why I have repeatedly distinguished human-written from human-authored throughout this discussion. In my mind, human-written is simply the antonym of machine-written.
If your understanding of these terms differs from mine, I would genuinely appreciate seeing your definitions. I increasingly suspect that we’ve been using the same words while referring to different concepts.
Perhaps the next iteration of the policy shouldn’t begin by debating whether we strongly prefer human-written contributions, but by agreeing what “human-written” actually means.
If the project is going to strongly prefer human-written contributions, then I think we owe contributors a clear definition of what “human-written” means. Otherwise I worry we’re expressing a strong preference for a term whose boundaries are left entirely to individual interpretation.
Best, Moritz
Thank you for your time Tom,The disagreement (as I understand) is this:My view: Policies should define the minimum framework necessary for collaboration between people who disagree.
My understanding of your view: Policies should also reflect the community’s collective values and preferences.
In that case let me bring up my previous analogy one more time, and let me know if you in principle agree with the following or not, and if not, why not?Best,Suppose that 50% of the community strongly preferred that all contributors develop on Linux, or that all documentation be written manually rather than with grammar or translation tools.
Would that fact alone justify expressing those preferences in project policy?
MoritzOn Sun, Jul 26, 2026 at 7:31 AM <amindfv@mailbox.org> wrote:> On 07/26/2026 1:57 AM CEST Moritz Angermann <moritz.angermann@gmail.com> wrote:
>
> Tom, your latest reply helped me understand something I hadn’t appreciated before.
>
> When I wrote “otherwise acceptable workflows,” you replied that this is exactly the point under discussion.
>
> > "Otherwise acceptable" is, of course, the point of discussion here.
>
> Does that mean that, in your view, LLM-assisted authorship is not an otherwise acceptable workflow, even when the contributor satisfies all of the policy’s requirements around disclosure, understanding, responsibility, and quality?
>
> If so, I think I finally understand why we have been talking past each other. In that case, the disclosure requirement is no longer merely about provenance; it identifies contributions produced by a workflow that the project itself does not regard as fully acceptable.
I'll just quote myself from a previous email:
"Currently 50% of 'voters' on the GHC GitLab feel that _any_ LLM usage is inappropriate. I think it would be valuable to consider how to make a policy that doesn't just please the people who want to use LLMs [...], but also recognizes that when a person makes an LLM contribution to the GHC GitLab, more than* half of the users there are thinking 'I wish you hadn't done that.'"
Saying "the contributor satisfies all of the policy’s requirements around disclosure, understanding, responsibility, and quality" puts the cart before the horse: policies about quality and understanding will be influenced by the community's feelings about LLMs.
Cheers,
Tom