Re: [PATCH] [v2] Documentation: Provide guidelines for tool-generated content

[Dave Hansen <dave.hansen@intel.com>]

On 11/11/25 15:45, NeilBrown wrote:
...
>> +Kernel contributors have been using tooling to generate contributions
>> +for a long time. These tools are constantly becoming more capable and
>> +undoubtedly improve developer productivity. At the same time, reviewer
>> +and maintainer bandwidth is a very scarce resource. Understanding
>> +which portions of a contribution come from humans versus tools is
>> +critical to maintain those resources and keep kernel development
>> +healthy.
> 
> "critical"?  Really?
> If I use "sed" to create a patch, it might be helpful for you to know
> that, but not critical.

I'll tone that down a bit.

> I also like the focus on "helping the reviewer".  That too is
> foundational.
> 
>   When submitting a patch you will benefit from efforts to build trust
>   with the maintainer, and anything you do to help the review process
>   run smoothly will help your patch get accepted.  Some guidelines for
>   how this applies with respect to tool-assisted patch creation, and LLM
>   (aka AI) in particular, are below.

To me, this veers a bit into a different area, which is explaining how
trust is important.

...>> + - Treat it just like any other contribution
>> + - Reject it outright
> 
> If I find that a maintainer might reject my tool-based submission
> outright, I might be tempted towards less transparency.
> I don't think we should legitimise this sort of response by listing it
> here.

I agree that this might steer an unscrupulous contributor into being
less transparent. But, I don't think this document is aimed at those
contributors in the first place.

They key question is whether maintainers in our project should have the
ability to reject a patch just because it was generated by a tool. I
think it would be silly for a maintainer to outright reject every bit of
content that was generated by a tool. But, it's equally silly to say
that maintainers should not have the ability to say that "tool $XYZ has
no place in the $ABC subsystem".

Maintainers can always say: "No". If they say it too much or for the
wrong reasons, we have a benevolent dictator for such situations.

>> + - Review the contribution with extra scrutiny
>> + - Suggest a better prompt instead of suggesting specific code changes
>> + - Ask for some other special steps, like asking the contributor to
>> +   elaborate on how the tool or model was trained
>> + - Ask the submitter to explain in more detail about the contribution
>> +   so that the maintainer can feel comfortable that the submitter fully
>> +   understands how the code works.
> 
> This last point contains an important idea that I think could be
> highlighted more.  The submitter needs to understand, and be able to
> defend, the submission; both its motivation and its content.
> "A tool generated the patch" is useful information but never an excuse
> for not understanding it.

This is fleshed out a bit more in v3. I hope you're able to take a look
at that when I post it as well.