Flyspray LuCI category

[Mathias Kresin]

27.09.2016 19:07, Ted Hess:
>> While creating such an issue template, it might be a good idea to
>> provide a small guide on how to write a good bugreport. Something
>> like the following:
>>
> A guide for submitting a bug report would probably be best added to our Website
> and/or the Wiki. Template text tends to either be ignored and or skipped over
> and just adds to the clutter in the report.

Well, if you are the opinion that a template text is skipped over how 
big is the chance that the same people check if the website/wiki 
provides a guide for reporting bugs?

Those are informations which should be present at the time a bug is 
reported.

> An interactive form which submits a
> formatted report makes more sense but is not something I would be adding.

I agree with you. The more steps need to be (forcefully) done, the 
bigger the chance is that the reporter doesn't make it to the submit button.

> As an experiment I added the following text to task creation:
> ------------
> Supply the following if possible:
>  - Device problem occurs on
>  - Software versions of LEDE release, packages, etc.
>  - Steps to reproduce
> ------------
>
> If it gets too messy, I'll probably remove it.

I still prefer to show the reporter how (s)he can get the information I 
need to fix the bugs. And I prefer not to ask the same questions over 
and over again. Yet it isn't a real issue, but as soon as LEDE gets more 
attention even inexpedience users will create bugreports.

Have a look at the OpenWrt bugtracker and judge by yourself about the 
quality of the submitted reports. But even LEDE received already 
bugreports which had so little informations that they were more or less 
useless. The best example for such a bugreport is 
https://github.com/lede-project/source/issues/250.

>> Metadata
>> - tested device
>> - used revision/used release (output of cat /etc/*_release on the router)
>> - self compiled or snapshot/release?
>>   - in case of a self compiled image: the output of
>> /path/to/LEDE/scripts/diffconfig.sh
>>
>> - Steps to reproduce
>> - Expected behaviour
>> - Actual behaviour

IMHO having informations about the expected behaviour is elementary. 
This way one can easily see if the reporter just tries to do something 
the wrong way.

Mathias