Re: [qemu-web PATCH] contribute: define clear limits on bug report volume

[Markus Armbruster <armbru@redhat.com>]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Thu, Sep 24, 2026 at 04:12:02PM +0100, Alex Bennée wrote:
>> It comes across as quite a draconian limit but to be honest after a 6
>> months of dealing with this flood I'm less inclined to be polite about
>> it:
>
> Yes it is draconian.  Aside from the periodic "mass filing"
> incidents, what prompted me is seeing the graph you produced
> at:
>
> https://www.qemu.org/screenshots/2026-09-culm-issues.svg

We're pulling the emergency brake.  Minor injuries must be accepted in
order to avoid major ones.

I'm not sure the policy gets that across.  "Not a benefit to the
project" and "place an unsustainable burden on maintainers" feel to me
like British understatement for "harm the project" and "threaten to
destroy the maintainer community".

> We see the increasing gap between open & closed bugs from
> March, where we failed to keep up with the flow arriving
> on qemu-security@nongnu.org
>
> In July we bulk imported the mails to gitlab, and between
> many maintainers we resolved alot over a month. After that
> first month though, we reverted to the widening gap, at
> the same rate we saw when triage was limited to just
> qemu-security@nongnu.org
>
> My reading of that is that even opening up triage to all
> QEMU maintainers has not fixed our scaling problem. We
> already burnt people out from dealing with these reports
> from automated tools.
>
> Ideally I would like reporters to put in more personal effort
> beyond the initial bug filing. If they do that then bugs might
> get through triage and patch review more effectively and get
> closed quicker, allowing filing of more reports.
>
> If reporters put in that more sustained patch curation effort
> instead of fire-and-forget, then I expect they wouldn't have
> time for filing so many bugs to begin with, making the limit
> less of a problem.

Wouldn't it be nice.

> Also if they're putting in greater effort, I'd be amenable to
> granting them an exception to exceed the limits on bug filing.
> IMHO any regular maintainers are implicitly exempt from the
> limits given their ongoing beneficial work for the project.
>
> IOW, the bug limit should be a problem primarily for people
> working on a "file-and-forget" basis.
>
>
> Still, I welcome suggestions for other ideas, or if we should
> have different limits in some level ? 

Submitters submit when they expect the effort to be worth their while.
I call this friction.  It helps deter low-value contributions.  It's
more effective when it can be felt upfront.

AI has lowered upfront friction for bug submitters.

AI has not yet materially lowered the cost of triage, review, etc.

The policy change doesn't restore upfront friction, it merely gives us
license to ignore certain submitters who flood us.

Sadly, I don't have any bright ideas on how to restore friction.