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

[James Bottomley <James.Bottomley@HansenPartnership.com>]

On Tue, 2026-01-13 at 13:43 -0500, Sasha Levin wrote:
> On Tue, Jan 13, 2026 at 10:20:44AM -0800,
> dan.j.williams@intel.com wrote:
[...]
> > So a simple rule of "generally you should be able to demonstrate
> > the ability to substantively review a contribution of similar
> > complexity before expecting the kernel community to engage in
> > earnest" mitigates the asymmetric threat of AI contributions *and*
> > contributors that have not built-up enough trust capital with their
> > upstream maintainer.
> 
> Looking at recent history (v6.12..v6.18) we had 1902 authors (a third
> of overall contributors) who contributed a single commit. Out of
> those 1902, only 177 have a Reviewed-by tag pointing to them.
> 
> With a rule like the above, 1700+ contributors would have not been
> able to send their patch in.

It's not just that.  Even today Reviewed-by: doesn't always mean the
subject of the tag actually understood it.  We do see a lot of patches
(particularly drivers from companies) that come to the lists  with
fully formed reviewed-by tags and no backing record.  Trying to
institute a reviewed-by requirement would drastically exacerbate this
and, even worse, produce a large uptick in pseudo reviews from people
trying to get the tag to submit.

Speaking as a drive by committer with quite a body of work, the worst
projects to come to are those with artificial worthiness metrics (like
n reviews or stars or github badges or whatever).  Even if you can be
bothered to get over the hump, whatever you did is usually irrelevant
to the patch you want to submit.

The best indication that a committer understood what they were touching
should be in the change log.  If they understand the system under
patch, they should be able to explain clearly why the patch is needed
and what its effects are.

Regards,

James