public inbox for linux-man@vger.kernel.org
 help / color / mirror / Atom feed
From: "Günther Noack" <gnoack3000@gmail.com>
To: Alejandro Colomar <alx@kernel.org>
Cc: linux-man@vger.kernel.org, "Mickaël Salaün" <mic@digikod.net>
Subject: Re: [PATCH] CONTRIBUTING.d/ai: Add guidelines banning AI for contributing
Date: Sun, 29 Mar 2026 15:42:03 +0200	[thread overview]
Message-ID: <20260329.5167693e9f38@gnoack.org> (raw)
In-Reply-To: <d6d3123c7271c11fc403906ee3971b22c2fe8e4c.1760476615.git.alx@kernel.org>

Hello!

On Tue, Oct 14, 2025 at 11:27:26PM +0200, Alejandro Colomar wrote:
> Signed-off-by: Alejandro Colomar <alx@kernel.org>
> ---
> 
> Hi!
> 
> I've already been DDoSed in my own home server by AI crawlers (which is
> the reason I decided to move the HTTPS server to port 80, just to break
> links and stop the madness.  I could install Anubis, but I'll resist for
> some time.
> 
> So far, I haven't noticed any contributors using AI.  Probably, the
> combination of relatively few people contributing documentation,
> combined with still working on a mailing list, has helped us avoid the
> wave of AI contributions.
> 
> However, it's better to take preventive measures.  AI is entirely banned
> in this project.  The guidelines are clear and concise.

I know I'm late to the discussion, but for the record, I would like to
throw a scenario into the discussion that I consider a compelling use
case for AI-assisted man-page contributions.

As you know, the Landlock man page work mainly consists of taking the
existing kernel documentation text and putting it into the man page
form.  That means that when producing the man page patches, the main
additional work is:

(a) formatting existing text in groff
(b) adapting the structure to match the man page format
(c) copy-and-pasting wording fixes between kernel and man page tree
    (in either direction)

Because this is tedious and time-consuming, and because the added
value over the existing kernel documentation is low, Landlock's man
pages tend to lag behind the kernel documentation by many months.

Coding agents are very good at such reformatting tasks though, and
that would make it potentially feasible to keep this up to date much
faster.  (with the rough process being that you point a coding agent
to the man page and Linux source trees and ask it to carry the
documentation changes over in a way that respects existing man page
style and structure). [^1]

Since the submitted man page text is the same as on the kernel side,
the main work done by the agent here is in Groff formatting, and in
finding the text in the kernel tree and putting it into the right man
page structure.

For inspiration, the Linux kernel itself has, after substantial
discussion, recently started adopting a different policy, where
AI-generated contributions are permitted, but where it is still made
clear that human contributors must review all AI-generated code and
have the same responsibilities as for a normal human-authored patch:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/coding-assistants.rst

I realize that the Landlock use case alone is maybe not enough to
change your stance on this, but I feel it's worth at least pointing
out that there are use cases with potential upsides.

I think that with a Linux-like policy for coding assistants, it would
be easier for us to keep the man pages up to date.

–Günther


Footnotes

[^1] An alternative that has been considered in the past was to create
     a mechanistic translation program to create the man pages from
     kernel .rst and .h files, but this also seems brittle and would
     mean that the man page structure would likely stay close to the
     kernel documentation in structure.  In my understanding, Linux's
     eBPF helpers use that approach.

  parent reply	other threads:[~2026-03-29 13:42 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-14 21:27 [PATCH] CONTRIBUTING.d/ai: Add guidelines banning AI for contributing Alejandro Colomar
2025-10-14 21:32 ` Carlos O'Donell
2025-10-14 21:52   ` Alejandro Colomar
2025-10-14 21:55     ` Carlos O'Donell
2025-10-14 21:39 ` Collin Funk
2025-10-14 21:59   ` Alejandro Colomar
2025-10-14 22:03     ` Carlos O'Donell
2025-10-14 22:10       ` Alejandro Colomar
2025-10-14 22:20         ` Alejandro Colomar
2025-10-14 23:59           ` Carlos O'Donell
2025-10-14 22:00   ` Carlos O'Donell
2025-10-14 22:16     ` Collin Funk
2025-10-14 23:58       ` Carlos O'Donell
2025-10-14 21:54 ` Carlos O'Donell
2025-10-14 22:15   ` Alejandro Colomar
2025-10-15  0:16     ` Carlos O'Donell
2025-10-15  2:13       ` Collin Funk
2025-10-15 10:49       ` Alejandro Colomar
2025-10-14 22:03 ` [PATCH v2] " Alejandro Colomar
2025-10-15 11:21 ` [PATCH v3] " Alejandro Colomar
2025-10-15 12:29   ` Alejandro Colomar
2025-10-15 13:25   ` Carlos O'Donell
2025-10-15 14:03     ` Alejandro Colomar
2025-10-15 14:46       ` Carlos O'Donell
2025-10-15 14:51         ` Sam James
2025-10-15 15:31           ` Alejandro Colomar
2025-10-15 16:09             ` Sam James
2025-10-15 16:20               ` Alejandro Colomar
2025-10-15 16:26                 ` Sam James
2025-10-15 15:50 ` [PATCH v4] " Alejandro Colomar
2025-10-15 16:03   ` Carlos O'Donell
2025-10-15 16:56     ` G. Branden Robinson
2025-10-15 18:11       ` Alejandro Colomar
2025-10-15 19:24         ` G. Branden Robinson
2025-10-15 19:50           ` Alejandro Colomar
2025-10-20 18:47           ` Carlos O'Donell
2025-10-20 19:05           ` Carlos O'Donell
2025-10-15 18:22     ` Alejandro Colomar
2025-10-15 18:49       ` Sam James
2025-10-15 19:03         ` Alejandro Colomar
2025-10-15 19:04           ` Alejandro Colomar
2025-10-15 19:11             ` Sam James
2025-10-15 19:17               ` Alejandro Colomar
2025-10-16 12:26       ` Alejandro Colomar
2025-10-16 16:41 ` [PATCH v5] " Alejandro Colomar
2025-10-20 18:25   ` Carlos O'Donell
2025-10-21 17:01     ` Alejandro Colomar
2025-10-27 17:29 ` [PATCH v6] " Alejandro Colomar
2025-10-28 12:31   ` Carlos O'Donell
2025-10-28 13:09     ` Alejandro Colomar
2025-10-28 13:21   ` [PATCH v7] " Alejandro Colomar
2025-11-10 11:54     ` Alejandro Colomar
2025-11-10 12:01 ` [PATCH v8] " Alejandro Colomar
2025-11-10 13:31   ` Carlos O'Donell
2025-11-10 14:31     ` Alejandro Colomar
2025-11-10 14:36 ` [PATCH v9] " Alejandro Colomar
2025-11-10 16:56   ` Carlos O'Donell
2025-11-10 22:25     ` Alejandro Colomar
2026-03-29 13:42 ` Günther Noack [this message]
2026-03-29 17:55   ` [PATCH] " Alejandro Colomar

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=20260329.5167693e9f38@gnoack.org \
    --to=gnoack3000@gmail.com \
    --cc=alx@kernel.org \
    --cc=linux-man@vger.kernel.org \
    --cc=mic@digikod.net \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox