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

[Demi Marie Obenour <demiobenour@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4029 bytes --]

On 8/4/26 12:41, Alyssa Ross wrote:
> It's been suggested to me a couple of times recently that having some
> statement about AI use in contributions would be helpful, for a couple
> of different reasons:
> 
>  • It resolves uncertainty contributors may feel about whether their
>    AI-assisted contributions will be welcome, since there is a wide
>    range of acceptance among open source software projects currently.
> 
>  • It teaches people submitting assisted contributions to avoid
>    pitfalls that might reduce the success of their contributions
>    without otherwise having been obvious to them.
> 
>  • It protects against precious reviewer time being spent trying to
>    sift through verbose and confusing LLM-generated descriptions,
>    which tends to be much less efficient for the reviewer.
> 
> I've tried to keep it as simple and minimally invasive as possible,
> focusing on remedying specific problems that are likely to come up.
> Each expectation has a brief explanation, because I expect people will
> be happier following the guidance if they understand the reason for
> it, but I've avoided going into too much detail to keep it easy to
> read, understand and remember the whole thing.  There's some slight
> deliberate ambiguity, because the important thing here is that people
> follow the spirit of the expectations.  They don't need to get in the
> way in situations where it would obviously make sense to do something
> different; for example I can imagine certain situations where it
> would be useful to share some LLM-generated prose.
> 
> Signed-off-by: Alyssa Ross <hi@alyssa.is>
> ---
> We had a conversation about this on Matrix a little while ago, and I
> hope this captures the consensus we had at the time.
> 
> I'm CCing everybody who's posted to the list recently (I think — sorry 
> if I missed someone), because it's of course important to make sure
> there's broad awareness of and agreement on the expectations.
> 
> I expect to apply this on top of my nav_order renumbering patch from
> earlier, so this would show up in the documentation index after 
> "Communication channels" and before "Sending Your Patch", since it's 
> important context for people to have before sending their first patch.
> 
>  Documentation/doc/contributing/ai.adoc | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)
>  create mode 100644 Documentation/doc/contributing/ai.adoc
> 
> diff --git a/Documentation/doc/contributing/ai.adoc b/Documentation/doc/contributing/ai.adoc
> new file mode 100644
> index 00000000..7535578e
> --- /dev/null
> +++ b/Documentation/doc/contributing/ai.adoc
> @@ -0,0 +1,23 @@
> += Use of AI in Spectrum contributions
> +:page-nav_order: 150
> +
> +// SPDX-FileCopyrightText: 2026 Alyssa Ross <hi@alyssa.is>
> +// SPDX-License-Identifier: GFDL-1.3-no-invariants-or-later OR CC-BY-SA-4.0
> +
> +Non-trivial Large Language Model (LLM) output in Spectrum contributions should
> +be clearly marked as such.
> +This is important context for reviewers, because humans and LLMs are prone to
> +different kinds of mistakes.
> +
> +LLM-generated prose is discouraged.
> +It tends to be overly verbose, and can be confusing because misunderstandings or
> +false assumptions tend to be more difficult to spot in prose from LLMs than from
> +humans.> +
> +Contributors should ensure they understand and are able to answer questions about
> +contributions they submit, in their own words.
> +It's generally unhelpful to send LLM output in response to questions, because it
> +can be expected that reviewers can ask LLMs questions themselves if LLM-generated
> +answers would be useful to them.
> +If a reviewer asks a contributor a question, it's because they want that
> +contributor's answer, not an LLM's.
> 
> base-commit: 9dc81e02d6382ef7fc89b9bb246a71ff0fcc68ff

What about LLM translation and LLM spelling/grammar checkers?
-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]