On Wed, May 10, 2017 at 4:16 PM, Alberto Salvia Novella < [email protected]> 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. -- Ubuntu-quality mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
