On Fri, Jun 06, 2025 at 09:52:49 +0100, Daniel P. Berrangé via Devel wrote:
From: Daniel P. Berrangé <berrange(a)redhat.com>
Bug reports from automated tools and AI agents are time consuming to
triage and have poor signal/noise ratio. Set strong expectations for
any reporters using such tools, in a (likely doomed) attempt to stem
the flow of poor quality reports.
Signed-off-by: Daniel P. Berrangé <berrange(a)redhat.com>
---
docs/bugs.rst | 14 ++++++++++++++
docs/securityprocess.rst | 4 ++++
2 files changed, 18 insertions(+)
diff --git a/docs/bugs.rst b/docs/bugs.rst
index 5fd1970caf..e12a6c74ec 100644
--- a/docs/bugs.rst
+++ b/docs/bugs.rst
@@ -76,6 +76,20 @@ Linux Distribution specific bug reports
like to have your procedure for filing bugs mentioned here, please mail the
libvirt development list.
+Use of automated tools / AI agents
+----------------------------------
+
+If any automated tool / AI agent is used to identify a bug / security
+flaw, the following additional expectations apply when filing a report:
+
+- The tool / agent used **MUST** be clearly declared in the description
+- All stated facts **MUST** be validated as correct and free from AI
+ hallucinations prior to filing
+- The problem **MUST** be described against an upstream release that is
+ no more than 3 months old.
+- The problem **SHOULD** be analysed and accompanied with a proposed
+ patch that can be directly applied to current git
I'd also like to prohibit/avoid vague and too general statements.
In the few last reports that were low quality that I've seen, the
problem statement and reproducer were true because they were too vague.
E.g. saying that "if you call this function with NULL argument it will
crash" can be true, but if we're making sure that it can't happen
elsewhere it's quite useless.
I'm not sure though how to formulate that.
Otherwise looks good and even like this:
Reviewed-by: Peter Krempa <pkrempa(a)redhat.com>