From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from atuin.qyliss.net (localhost [IPv6:::1]) by atuin.qyliss.net (Postfix) with ESMTP id DA72C89F5; Wed, 05 Aug 2026 08:15:20 +0000 (UTC) Received: by atuin.qyliss.net (Postfix, from userid 993) id 5EC1F8A5E; Wed, 05 Aug 2026 08:15:18 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on atuin.qyliss.net X-Spam-Level: ** X-Spam-Status: No, score=2.4 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,DMARC_MISSING,FROM_SUSPICIOUS_NTLD,PDS_OTHER_BAD_TLD, SPF_HELO_NONE autolearn=no autolearn_force=no version=4.0.1 Received: from mail-108-mta126.mxroute.com (mail-108-mta126.mxroute.com [136.175.108.126]) by atuin.qyliss.net (Postfix) with ESMTPS id A64428A5C for ; Wed, 05 Aug 2026 08:15:16 +0000 (UTC) Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta126.mxroute.com (ZoneMTA) with ESMTPSA id 19fd0fdac0f000c8ef.002 for (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Wed, 05 Aug 2026 08:15:13 +0000 X-Zone-Loop: 55752c6be83fd0117252debd8650ef61870e306e84e0 X-Originating-IP: [136.175.111.3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gagarin.work; s=x; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: From:References:To:Subject:MIME-Version:Date:Message-ID:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=kN9Y/5mNlA95sXFJ9gmMLq/B4moH4gq7TnaOkuLXYhk=; b=Q/CaneRjpDycFJcI9PFo006Tb3 qSfp0IRbNUMNq3iwaLXhoHrQAe/J7gnCwqPuWzQ42oyHkB8qxz4aW55XS0hPNj0gW6btWO+2P+Ja0 iIjTW6MAF7wpklyW+VXIyOfQcmOL7tyk3yhUioPAmyMt1OPQ4WPkfao7DJSRu8O2JD8ZQthVq8P9J zXF8pON2xB929g6ng2xLPwqeWNdAcAUyKDr5OtpjuSL9L1jP/JUCkhWvgi3hnkJmyiw7qxGgWueqB h1kUioaWPBgAlopUQmY+QeLSM5Fh8lJPQLkf0LyOWOpQAw5nA0joUlsuGR/fGtzXWrQpnrkIY3HAQ z2tHVGxA==; Message-ID: <05840f25-32fd-4953-885e-4a11845d102c@gagarin.work> Date: Wed, 5 Aug 2026 10:15:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Documentation: document expectations around AI use To: Alyssa Ross , devel@spectrum-os.org References: <20260804164109.175987-2-hi@alyssa.is> Content-Language: en-US From: Valentin Gagarin In-Reply-To: <20260804164109.175987-2-hi@alyssa.is> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Authenticated-Id: valentin@gagarin.work Message-ID-Hash: 4HTLC4WTF5DYJM2KYKJT3NPLTYJICYMA X-Message-ID-Hash: 4HTLC4WTF5DYJM2KYKJT3NPLTYJICYMA X-MailFrom: valentin@gagarin.work X-Mailman-Rule-Hits: member-moderation X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; loop; banned-address; header-match-devel.spectrum-os.org-0; header-match-devel.spectrum-os.org-1; header-match-devel.spectrum-os.org-2; header-match-devel.spectrum-os.org-3; header-match-devel.spectrum-os.org-4; emergency X-Mailman-Version: 3.3.10 Precedence: list List-Id: Patches and low-level development discussion Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: 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.