Re: Ballot option: Allow AI-Assisted Contributions

Lucas Nussbaum <[email protected]> Thu, 23 Jul 2026 21:50:47 +0200
Newsgroups	gmane.linux.debian.devel.vote
Message-ID	<[email protected]>
Hi, Tiago,

On 23/07/26 at 14:57 -0400, Tiago Bortoletto Vaz wrote:
> Hello Lucas,
> 
> Thanks for adding this ballot.
> I have a question and a few comments if you don't mind.
> 
> [...]
> 
> > 
> > 4. **Explicit Disclosure:** When a significant portion of the contribution
> >    is taken from a tool without manual modification, contributors should
> >    disclose the tool's use. This may be recorded using Git trailers, such as
> >    `Generated-By:` or `Assisted-By:`.
> 
> I'd avoid proposing the tool here. I fear our commits will be infected by badly
> intended promotion of this or that tool. Perhaps you could rephrase it a bit to
> encourage the disclosure of AI usage, without mentioning the tool behind it
> specifically?
> 
> > 5. **Prior Discussion of Bulk or Automated Changes:** Similarly to the
> >    mass-bug filing process (Developers Reference section 7.1.1),
> >    contributors should discuss their intention before submitting bulk or
> >    autonomously generated contributions. Any such automated process should
> >    be overseen by a human who remains accountable for its behavior and
> >    output.
> > 
> > 6. **Community Courtesy:** To respect the preferences of project members who
> >    wish to avoid AI-generated content, contributors should clearly label
> >    such content in mailing list and bug discussions (e.g., by identifying
> >    such content with a clear disclaimer or a machine-readable tag like
> >    `[AI-Generated]`).
> 
> My feeling is that the above will legitimise the use of 'AI-generated' content
> in your mailing lists and the BTS. Experience has shown that this usually
> triggers a wave of negative reactions that I'd rather avoid. I'd actually argue
> for merging 4 and 6 by making it clear that AI-generated or heavily assisted
> content is never accepted in Debian without disclosure, without enforcing any
> specific means or mentioning any specific areas (mailing lists, bts, salsa,
> etc.) where this should be applied.

Thanks for the feedback.
I agree with both points.

Here is an amended version:

@@ -45,10 +45,13 @@ generated by an LLM), provided the following conditions are met:
    Contributors should fully understand the proposed changes and be prepared
    to justify them.

-4. **Explicit Disclosure:** When a significant portion of the contribution
-   is taken from a tool without manual modification, contributors should
-   disclose the tool's use. This may be recorded using Git trailers, such as
-   `Generated-By:` or `Assisted-By:`.
+4. **Disclosure:** When a significant portion of a contribution is generated
+   or substantially assisted by a tool, contributors should disclose the use
+   of the tool, making it clearly visible to the intended audience. This
+   covers all forms of contribution, including code, mailing list posts, and
+   bug discussions. The form of the disclosure is left to the contributor; one
+   convenient option for commits is a Git trailer such as `Generated-By:` or
+   `Assisted-By:`.

 5. **Prior Discussion of Bulk or Automated Changes:** Similarly to the
    mass-bug filing process (Developers Reference section 7.1.1),
@@ -57,13 +60,7 @@ generated by an LLM), provided the following conditions are met:
    be overseen by a human who remains accountable for its behavior and
    output.

-6. **Community Courtesy:** To respect the preferences of project members who
-   wish to avoid AI-generated content, contributors should clearly label
-   such content in mailing list and bug discussions (e.g., by identifying
-   such content with a clear disclaimer or a machine-readable tag like
-   `[AI-Generated]`).
-
-7. **Confidentiality and Privacy:** Contributors must not use generative AI
+6. **Confidentiality and Privacy:** Contributors must not use generative AI
    tools that transmit data to untrusted providers with non-public or
    sensitive project information (such as embargoed security reports or
    private communication), as this may lead to the unintended disclosure of

(The current full version can be found at
https://salsa.debian.org/lucas/ai-gr/-/blob/main/README.md?ref_type=heads
; that change is
https://salsa.debian.org/lucas/ai-gr/-/commit/d20773f33a485bfe114974a26c0eee922df6fd96
)

Regarding promotion of specific tools, I think that "The form of the
disclosure is left to the contributor" is sufficient to ensure that
contributors do not feel forced to promote a specific tool. On the other
hand, knowing which tool was used can also be useful to learn from
others' practices, so I don't think that it should be discouraged to
name the tool.

> > 7. **Confidentiality and Privacy:** Contributors must not use generative AI
> >    tools that transmit data to untrusted providers with non-public or
> >    sensitive project information (such as embargoed security reports or
> >    private communication), as this may lead to the unintended disclosure of
> >    confidential data.
> 
> By 'untrusted providers' do you mean anything != *.d.o ? Shouldn't it be more
> clear?

Not necessarily: we have different levels of confidentiality inside
Debian (for example: private GPG-encrypted email discussions vs
debian-private). Some inference providers could be trusted for the
second case (after all, we already trust the email providers of every
subscriber) but not for the first case. So I'd rather keep it vague.

Lucas
signature.asc (application/pgp-signature, 833 B)