Showstopper bug report (17.04): WiFi not working

[J]

On Tue, May 9, 2017 at 5:58 AM, Alberto Salvia Novella
<es20490446e at gmail.com> wrote:
> After a period of a week nobody opposed, and I have addressed all the
> individual issues that people reported about it.

Ok... below.

> Moreover my latest poll was also performed outside of Ubuntu. And it showed
> that were half the outsiders disagreed, hundred percent of insiders
> disagreed. And the polls were verbatim.

Link? the last poll I saw was one about adding unnecessary external
artwork to which 100% of respondents said "No"

> So in my view I cannot take disagreement too seriously here. I'm open to
> consider any option, except staying the same that proves not to work.

But you wanted critque, so here it is:

> Etiquette
> Keep in mind that many software in Ubuntu is maintained by people in their spare time, brought to you for free.

This seems pretty incomplete.  So what if people maintain it in their
spare time?  What consideration should I provide here because of this
statement?  This isn't a rule of etiquette, this is just a statement
about where it comes from.

> If you care about an Ubuntu release not having bugs, test the daily image five months before launch. So developers have time to fix it.

Since you suggest I test the daily image... how do I do that?  Where
do I learn more?  What is the process for testing?  How do I get these
images?  You suggest potentially new and inexperienced testers do a
thing, then fail to tell them how to do that thing, or where to find
more information on doing that thing.

> If writing more doesn't make a tangible difference, write less.

What does this mean?  To someone who has never written a bug, or
written very few, what is tangible between more and less?  YOU may
know, I may know, Brian may know, but the newbie who just downloaded
Ubuntu for the first time has no idea what is and isn't worth
mentioning in a bug report, and as someone who FIXES bugs, I would
much rather have too much info than a bug report that is simply "X
doesn't work" which is the "less" end of the spectrum.

> If you have any doubt, you can ask any time.

You should also point them to IRC.

> Not bugs
> You shouldn't file a bug here if you are:

> Using a BIOS or firmware which can be causing the problem

I'm a newbie, how the heck do I know if BIOS can be causing a problem?
 So because I have firmware (and know nothing about firmware, so
theoretically, it COULD be a cause) I shouldn't report a bug?  There
are plenty of times where you don't know it's firmware until well
after the bug has been filed, triaged and investigated.

> Requesting support

Bugs ARE support requests.  They are "I am having trouble running X
because Y happens which prevents me from using X"

> Requesting new software

Feature Requests ARE valid bugs, LP and Github are FULL of feature request bugs.

> Discussing ideas

That I can agree on, bugs are not meant for discussion, but you don't
really tell people how to find the appropriate avenue for discussing
those ideas.

> Using software outside the official repositories

I use all sorts of software outside of official repositories, so I
should never file a bug?  Because that is how that item reads to me.
This says, exactly, "You shouldn't file a bug if you are using
software outside the official repositories"

> Reporting misspells

Misspellings, typos and other minor issues are still valid bugs.  Why
shouldn't they report them?

The point is, the original version of this actually took the time to
explain WHY these don't count, and provided other means to address
these issues.  You just tell users to not file bugs and provide no
other information beyond that.

> Reporting windowed applications
> In the Terminal application enter:

> ubuntu-bug -w

> Reporting non windowed applications
> 1. Using the Synaptic application and the list of common packages, determine which software package is the most likely to be affected.

Use Synaptic for what?  I don't use synaptic and I've been using
Ubuntu for almost 10 years now, I've NEVER used or even installed
synaptic.  I'm a newbie, how do I use Synaptic to file a bug?  Again,
you suggest doing a thing without telling newbies how to do that
thing.  What about determining the command used and dpkg -S to find
the package?  You give no screenshots to explain what you're telling
people to do, so someone who has never seen those tools will have no
idea what to expect and could end up blindly clicking "things" hoping
they are correct.  Remember the discussion about imagery?  THIS is
where images are appropriate, to highlight and further explain a plain
text statement.

> 2. In the Terminal application enter the following, substituting PACKAGE with your package name:

> ubuntu-bug PACKAGE

What happens when ubuntu-bug tells me a package is not an official
ubuntu package?

> 3. Or if you haven't been able to determine the package, just enter:

> ubuntu-bug

> Reporting offline systems
> If the system internet does't work, do the following:

You mispelled "doesn't" here, but that's not a bug, as you point out
above, so forget I said anything.

> 1. On the target system, in the Terminal application enter the following. Substituting PACKAGE with your package name:

> For a crash:
> apport-cli -p PACKAGE --save bug.crash

Screenshot

> For a any other issue:
> apport-cli -f -p PACKAGE --save bug.apport

Screenshot

> 2. Copy the generated file to the system used for filing the report.

Copy how? (Yes, there are cases where this is NOT obvious to the user)

> 3. On that reporting system, in the Terminal application enter the following. Substituting FILE with your file name:

> ubuntu-bug -c FILE

so no path is necessary?  Ubuntu will just "know" where FILE is
without the full path to /media/USERNAME/dir/dir/FILE?

Since we're talking about using an external system, now you've told
users they must have TWO Ubuntu systems.  How do I file a bug from
Windows?  Or OSX?  You half-way explain that below, but there is
nothing tying this step from a non-Ubuntu system to that step below.

> Reporting unusable systems
> Only if you system doesn't fit any of the above methods go to the following site, substituting PACKAGE with your package name:

This is not worded well, IMO.  "If your issue cannot be reported using
any of the above methods, ..."  And we haven't really discussed a
total catastrophic failure, this needs more explanation about when to
use this option, the last resort.

> https://bugs.launchpad.net/ubuntu/+source/PACKAGE/+filebug

But when I go to Launchpad and search for PACKAGE, I get
https://bugs.launchpad.net/PACKAGE/+filebug, what does this mean?  Is
this still the right place?  I think this still needs expanding.  What
is the difference between them, when should I file bugs at one, but
not the other? There are plenty of cases where bugs filed at
ubuntu/+source/PACKAGE/+filebug languish for months without being
touched, where launchpad.net/PACKAGE/+filebug notifies the upstream
directly and gets a resolution MUCH faster.

> Or if you haven't been able to determine the package:

> https://bugs.launchpad.net/ubuntu/+filebug

ANd do what once I'm there?  What info should I include? Which of
these fields do I need to fill in and which can i leave alone?  What
severity do I set it?  What is a status? what are the next steps?
When will my bug be looked at?  What do I do when my bug has sat for
three weeks untouched?  Where can I find more information?

You've basically removed all the valuable and informative bits for a
set of unexplained instructions with no context for people who are new
to filing bugs against Ubuntu packages.