From: Alyssa Ross <hi@alyssa.is>
To: Demi Marie Obenour <demiobenour@gmail.com>
Cc: devel@spectrum-os.org, "Valentin Gagarin" <valentin@gagarin.work>,
"Vaida Plankytė" <vaidaplankyte@gmail.com>,
Yureka <yuka@yuka.dev>, colbyt <colby@colbyt.com>
Subject: Re: [PATCH] Documentation: document expectations around AI use
Date: Wed, 5 Aug 2026 18:23:17 +0200 [thread overview]
Message-ID: <anNixX7rfkojeZa_@fw12.qyliss.net> (raw)
In-Reply-To: <8fbfc3eb-7910-4570-bab7-064041483f8a@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4872 bytes --]
On Tue, Aug 04, 2026 at 04:58:45PM -0400, Demi Marie Obenour wrote:
> 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?
I think it would be difficult to argue that spelling/grammar checkers
are non-trivial LLM output or produce LLM-generated prose, no?
Translation I think is covered by "LLM-generated prose is discouraged."
It's not forbidden, so people can use it if they really need to, but
it's probably unhelpful in comparison to posting human generated text,
even if that's in another language. That allows others who speak the
language to understand the original, and non-speakers without access to
a human speaker can use translation tools themselves, and with the
original text even have the option to use multiple if one tool produces
results that seem unclear or implausible.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-08-05 16:23 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-04 16:41 [PATCH] Documentation: document expectations around AI use Alyssa Ross
2026-08-04 20:58 ` Demi Marie Obenour
2026-08-05 16:23 ` Alyssa Ross [this message]
2026-08-05 8:15 ` Valentin Gagarin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=anNixX7rfkojeZa_@fw12.qyliss.net \
--to=hi@alyssa.is \
--cc=colby@colbyt.com \
--cc=demiobenour@gmail.com \
--cc=devel@spectrum-os.org \
--cc=vaidaplankyte@gmail.com \
--cc=valentin@gagarin.work \
--cc=yuka@yuka.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://spectrum-os.org/git/doc
https://spectrum-os.org/git/mktuntap
https://spectrum-os.org/git/spectrum
https://spectrum-os.org/git/ucspi-vsock
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).