On Fri, Feb 10, 2023 at 09:50:25 +0000, Daniel P. Berrangé wrote:
On Fri, Feb 10, 2023 at 10:34:11AM +0100, Andrea Bolognani wrote:
> Hopefully including this request in ALL CAPITAL LETTERS in the
> issue template will cut down on the number of screenshots that
> end up cluttering bug reports by at least a tiny bit.
>
> Signed-off-by: Andrea Bolognani <abologna(a)redhat.com>
> ---
> .gitlab/issue_templates/bug.md | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.gitlab/issue_templates/bug.md b/.gitlab/issue_templates/bug.md
> index f220671a06..b923be0ca0 100644
> --- a/.gitlab/issue_templates/bug.md
> +++ b/.gitlab/issue_templates/bug.md
> @@ -17,3 +17,4 @@
> ## Additional information
> <!-- Attach XML configs, logs, stack traces, etc. Compress the files if
necessary -->
> <!-- See
https://libvirt.org/kbase/debuglogs.html on how to configure logging
-->
> +<!-- Please DO NOT ATTACH SCREENSHOTS to the bug report. Provide all information
as plain text -->
I think this is pretty user hostile. When filing bugs, the more rules a
project imposes on the bug report, the less likely I am to go ahead with
filing it, especially when the rules are worded in a very direct manner
that makes it feel like you'll be flamed for getting it wrong.
IMHO if someone provides a bug report with a screenshot and there is not
sufficient accompanying information, just nicely ask them to explain the
problem in a little more detail. We need todo that with plenty of bugs
which don't have screenshots either, and screenshots can be helpful in
some cases.
Screenshots indeed can be useful, it's just whent the user posts a
screenshot of logs or the XML config which is extremely inconvenient.
Thus I agree that disallowing screenshots is not something we want to do
generally, but we should encourage users not to screenshot
text/logs/xmls.
As I wrote in a different subthread, we IMO need a minimalistic version
of the page which instructs what to do without the extra clutter. Where
we can write a bit more than here, but I agree that we should not add
much more information here.
The balance of simplicity vs putting all the required information is
hard to strike as it's to see in the 'debuglogs' kbase page which grew a
bit too much (by my hand unfortunately) after users were having repeated
problems with configuring logging. At this point the article is a big
wall of text and while there's guidance we IMO need also a minimal
version of that page to go with the bug reporting howto.