Re: [libvirt PATCH] gitlab: Ask users not to attach screenshots to bug reports

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&gt; > > --- > > .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.