Re: [PATCH 3/4] AGENTS.md: let agents know what the participation rules are

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Sep 21, 2026 at 02:12:32PM +0200, Paolo Bonzini wrote:
> Il lun 21 set 2026, 13:11 Daniel P. Berrangé <berrange@redhat.com> ha
> scritto:
> 
> > > > +### No automated posting
> > > > +
> > > > +Agents **must not** use any API, CLI, or web UI automation to:
> > > > +
> > > > +- Interact on the QEMU mailing lists
> > > > +- Create, edit, or close **issues ("work items")**
> > > > +- Post **comments** on merge requests, issues or commits
> > > > +- Open or update **merge requests (MRs)**.  QEMU does not use merge
> > requests anyway.
> > > > +
> > >
> > > Are we considering project agents (such as the stsquad-bot) exempt from
> > > this policy? I'm not sure what a normal agent can do via the API as it
> > > wouldn't have the project level access the stsquad-bot needs.
> >
> > At least a user's agent can likely bulk file work items without elevated
> > access privs, as we've seen by the several slop-bombs we've had.
> >
> > I'd add a footnote for that along the lines of:
> >
> >  'Official project agents whose code is maintained under
> > gitlab.com/qemu-project
> >   may be exempted from one or more of these rules, at the discretion of
> > the QEMU
> >   project maintainer(s)'
> >
> 
> Sure.
> 
> > > +### No AI-written text must reach maintainers
> > > > +
> > > > +These rules apply when publishing AI-assisted work to GitLab or the
> > mailing list:
> > > > +
> > > > +- **AI-written cover letters and commit messages are banned**.  These
> > are
> > > > +  easy to recognize and waste reviewers' time.
> > > > +- **AI-generated responses to reviewer comments are banned**. This
> > undermines
> > > > +  the human-to-human interaction fundamental to code review.
> > > > +- **AI-written issue ("work item") descriptions or comments are
> > banned**. These
> > > > +  are verbose and waste triagers' time.
> > > > +  - An exception is made for issues for defects detected by automated
> > or
> > > > +    semi-automated tooling, including fuzzers and LLM-assisted defect
> > > > +    detection.  Such issues must be reviewed by a human before
> > creation,
> > > > +    must be created by a human and communication with maintainers must
> > > > +    be done by a human, but including the verbatim tool output in the
> > > > +    issue description is explicitly allowed.
> >
> > I kind of want to eliminate this exception. IMHO from the bugs we're
> > getting, I think human's are often putting very little effort into
> > reviewing the tools output, such that it is largely a box ticking
> > exercise to claim they've reviewed it.
> >
> > If we removed the exception, and required humans to write up the
> > finding of the fuzzer/detect detection in human language, that
> > may do a better job of getting people to engage in more critical
> > thinking rather than rubber stamping the tool output.
> >
> > It would limit the ability of people bulk file 50+ tickets in a day.
> >
> 
> I think that's the problem, namely not realizing there's someone on the
> other side.
> 
> LLM write-ups are essentially the same as patents, they look like English
> but they're not; and the verbosity of the write-ups is sometimes a curse
> and sometimes a blessing. There is a tension between having a simple
> description of the issue and an unopinionated one. The fix is not always
> trivially obvious, and sometimes the "executive summary" from the LLM
> points in the wrong direction—I have no expectation that human reporters
> will be any better at not misleading me.

The difference though is that when I put effort into responding to
a wrong executive summary written by the human, it is still potentially
a reasonable use of my time as they might learn something from the
exchange.

Responding to a wrong executive summary from the bot sucks the will to
live as you know it won't improve things next time around.


> In fact I'd rather like us to introduce an explicit rule that a person/
> > tool must not file more than about 5 tickets in a single day, without
> > prior approval from maintainers, so we don't get bombarded at such a
> > high rate.
> >
> 
> Sure, that's a good idea. Even 5 per month...

I wouldn't want to limit organically found bugs quite that low, but
for automated bug discovery we need to stem the flow, and set a
stronger expectation for the contributor writing a patch and taking
responsibility to submit it via qemu-devel.

Ideally we would get people sending patches directly to the list
without the bug tracker at all, except for security bugs - which
needs the security classification work:

  https://lists.gnu.org/archive/html/qemu-devel/2026-09/msg03555.html

With regards,
Daniel
-- 
|: https://berrange.com       ~~        https://hachyderm.io/@berrange :|
|: https://libvirt.org          ~~          https://entangle-photo.org :|
|: https://pixelfed.art/berrange   ~~    https://fstop138.berrange.com :|