[Ubuntu-bugcontrol] I have written a draft for the Reporting Bugs guide

[C de-Avillez]

On Sun, 28 May 2017 16:54:45 +0200
Alberto Salvia Novella <es20490446e at gmail.com> wrote:

> About:
> (https://help.ubuntu.com/community/ReportingBugs)
> (https://wiki.ubuntu.com/es20490446e/Reporting%20bugs)

OK, let's get thru the proposed page.

I will be copying text from the proposed Reporting Bugs so that I can
comment. The version I am using is #32, timestamped 2017-05-27 22:38:52.

Text copied will have the usual "> " we see on replies (well, at least
*I* see on my text emails. I do not know what/how it is shown on
HTML/richText).

* 1. Etiquette

> 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.

Why 5 months before? Our release cycle is *still* 6 months. If we test
an image 5 months before release, we will be testing pre-alpha code.

* how are people -- non-technical people -- going to test it?
  Something that is, 5 months before release, pre-alpha?
* should they only test the code as is 5 months before release?

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

We need context. If fact, the sentence above is a good example of why
writing *less* does not always help.

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

I absolutely agree. 100%. All for it. Always.

But...

My issue here is the word "ask", above, is a link to mailing to the
ubuntu-quality ML. Nothing else. But the ubuntu-quality mailing list is
NOT the only resource available for people in doubt. There are also:

* IRC
* The Ubuntu fora (https://ubuntuforums.org)
* AskUbuntu (https://askubuntu.com/)
* the answers section on Launchpad (https://answers.launchpad.net/)
* the ubuntu-users mailing list
* the Ubuntu documentation (https://help.ubuntu.com/)
* and MANY other mailing lists.

To limit to ONE source for answers really does not help. At all. And it
is not even the most important source for bugs/issues/support.

2. Not Bugs

> Reporting misspells

But a misspell *is* a bug. Why wouldn't a mispell be reported?

3. Reporting windowed aplications

> In the Terminal application enter:
> 
> ubuntu-bug -w

Ah, OK. And then this ubuntu-bug thingie will magically find the bug I
want to report, right? Oh, it will not? what should I do then?

4. 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.

But synaptic is no longer installed by default. How is a casual user
going to *know* that, and how would this casual user get synaptic
installed? Are there other options? What are they?

5. Reporting unusable systems

Now we have, as far as I am concerned, a real issue. As I have already
stated, we do not simply need more bugs, we need *good*, *workable*,
bugs. Our experience with free bug entry was horrible. many of the bugs
entered were unworkable. This was why the free bug entry was removed
from view. 

-x-x-x-x-x-x-x-x-

This is one reason of why reporting bugs is so complicated. It is not
*easy* to report a bug. Keep in mind that a bug report is a *technical*
report of a software defect.

If one does not know what a bug is (hint: a bug is a defect in a
program/package), why should one be able to enter *anything* as a bug?

If one does not know if the bad experience just had is, or is not, a
bug, then one would be better served by going to the community support
areas I pointed above. If necessary, after being helped by somebody else
in the community -- and if determined to be a bug -- then a bug may be
opened. But know, at least, we have a good chance of knowing the correct
package name, and  other important details to be reported.

Cheers,

..C..




-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20170529/7a82a568/attachment.pgp>