[PATCH v2 07/14] docs: security-bugs: first-time reporters must send a single report first

[Willy Tarreau <w@1wt.eu>]

The security team regularly receives series of reports from first-time
reporters, all of them suffering from the same issues (missing fix,
wrong format, missing information), which need to be addressed one at a
time and put unneeded pressure on maintainers. Worse, the security team
ends up having to respond to each one of these messages so that CCed
maintainers know about the problem.

Let's ask first-time reporters to send only one report, and to wait for
confirmation that it is in the expected form before sending the other
ones. Also make it clear that violating this rule shows that the
reporter did not read the doc, and that such reporters should be
prepared not to receive any response.

Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
 Documentation/process/security-bugs.rst | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/Documentation/process/security-bugs.rst b/Documentation/process/security-bugs.rst
index 38bdb2354353e..437f3cb29e80a 100644
--- a/Documentation/process/security-bugs.rst
+++ b/Documentation/process/security-bugs.rst
@@ -303,6 +303,15 @@ exception is when an issue concerns closely related parts maintained by the
 exact same subset of maintainers, and these parts are expected to be fixed all
 at once by the same commit, then it may be acceptable to report them at once.
 
+If this is your first report, send only one, and wait for confirmation that it
+is in the expected form before sending the other ones as individual messages.
+The vast majority of first reports need to be adjusted, and otherwise the same
+mistakes are repeated in all of them, putting needless pressure on the
+maintainers and on the security team.  Violating this rule is a clear
+indication that the reporter did not read this document, and such reporters
+should be prepared not to receive any response at all, as maintainers and the
+security team have better things to do than to repeat what is written here.
+
 Please send **plain text** emails without attachments where possible.
 It is much harder to have a context-quoted discussion about a complex
 issue if all the details are hidden away in attachments. Archives (zip, tar,
-- 
2.52.0