I have written a draft for the Reporting Bugs guide

Dario Ruellan dario.ruellan at gmail.com
Thu May 11 12:49:19 UTC 2017


On Wed, May 10, 2017 at 4:16 PM, Alberto Salvia Novella <
es20490446e at gmail.com> wrote:


> What if we took advantage of the capability of wikis to abstract pages,
> and we make a guide that is concise, but provides generous amount of detail
> on sub-pages?
>

I think that can be the way to go. Looking at the current documentation, we
can divide the thing into this categories:

Application crash
System crash
Non-crash bugs for apps
Non-crash bugs for system
Translation bugs

and not present but implicit:
non-bugs but actually feature requests

Now, application crash and system crash can have automated reports, so,
this guide is going to be useful only if the user wants to fill a manual
report. Seems that the guide is using three approaches

Manually on Launchpad
Using Apport on an open window
Using Apport on a specific package
Messing with the Apport config file to enable some options that perhaps are
disabled on a stable release.

The last one looks a bit overkill. It is nice to know this if you're
planning to be a regular bug reporter, but for a one-time reporter I don't
think is going to work.

About the manual use of Apport, I don't remember if you need a Launchpad
account to file a bug this way. If NOT, then, I prefer the Launchpad
approach, since otherwise can be difficult to follow up the bug, if you
need more details from the reporter.

So, in the end, this document can be the "advanced" guide, and the simple
or quick guide can be something like:

System freeze -> gather information -> Launchpad -> search for similar bugs
-> report
System bug -> is it really a system bug? -> update -> gather information ->
Launchpad -> search for similar bugs -> report
App bug -> is it really an app bug? -> update -> gather information ->
Launchpad -> search for similar bugs -> report
Missbehaving of system/app -> is it really a bug? -> update -> gather
information -> Launchpad -> search for similar bugs -> report
Translation bug -> determine the app -> update -> Launchpad -> search for
similar bugs -> report
Feature requests -> go somewhere

-- + -- + -- + -- + -- + --

So, the question here is: we need this simplification? The idea is to
gather more bugs from regular users. Alberto is stating that many people
has problems with the current documentation, and after reading the guide, I
can say that can be a bit technical. But that can be actually the point:
filter regular users from the ones that have the knowledge and dedication
for this.

-- + -- + -- + -- + -- + --


> Do in private, so we can keep the conversation as light as possible till
> we finally get it to the public.
>
>
I have no problem leaving this in public, in fact, could be nice to first
gather consensus regarding the actual documentation.


More information about the Ubuntu-quality mailing list