<div dir="auto">Something I'm missing on those tutorials is the recommendation for search for updates before reporting the bug, just in case the problem is already fixed.<div dir="auto"><br></div><div dir="auto">Seem important for me, but I like to hear a second opinion about it.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On May 29, 2017 10:50 PM, "C de-Avillez" <<a href="mailto:hggdh2@ubuntu.com">hggdh2@ubuntu.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, 28 May 2017 16:54:45 +0200<br>
Alberto Salvia Novella <<a href="mailto:es20490446e@gmail.com">es20490446e@gmail.com</a>> wrote:<br>
<br>
> About:<br>
> (<a href="https://help.ubuntu.com/community/ReportingBugs" rel="noreferrer" target="_blank">https://help.ubuntu.com/<wbr>community/ReportingBugs</a>)<br>
> (<a href="https://wiki.ubuntu.com/es20490446e/Reporting%20bugs" rel="noreferrer" target="_blank">https://wiki.ubuntu.com/<wbr>es20490446e/Reporting%20bugs</a>)<br>
<br>
OK, let's get thru the proposed page.<br>
<br>
I will be copying text from the proposed Reporting Bugs so that I can<br>
comment. The version I am using is #32, timestamped 2017-05-27 22:38:52.<br>
<br>
Text copied will have the usual "> " we see on replies (well, at least<br>
*I* see on my text emails. I do not know what/how it is shown on<br>
HTML/richText).<br>
<br>
* 1. Etiquette<br>
<br>
> If you care about an Ubuntu release not having bugs, test the daily<br>
>  image five months before launch. So developers have time to fix it.<br>
<br>
Why 5 months before? Our release cycle is *still* 6 months. If we test<br>
an image 5 months before release, we will be testing pre-alpha code.<br>
<br>
* how are people -- non-technical people -- going to test it?<br>
  Something that is, 5 months before release, pre-alpha?<br>
* should they only test the code as is 5 months before release?<br>
<br>
> If writing more doesn't make a tangible difference, write less.<br>
<br>
We need context. If fact, the sentence above is a good example of why<br>
writing *less* does not always help.<br>
<br>
> If you have any doubt, you can ask any time.<br>
<br>
I absolutely agree. 100%. All for it. Always.<br>
<br>
But...<br>
<br>
My issue here is the word "ask", above, is a link to mailing to the<br>
ubuntu-quality ML. Nothing else. But the ubuntu-quality mailing list is<br>
NOT the only resource available for people in doubt. There are also:<br>
<br>
* IRC<br>
* The Ubuntu fora (<a href="https://ubuntuforums.org" rel="noreferrer" target="_blank">https://ubuntuforums.org</a>)<br>
* AskUbuntu (<a href="https://askubuntu.com/" rel="noreferrer" target="_blank">https://askubuntu.com/</a>)<br>
* the answers section on Launchpad (<a href="https://answers.launchpad.net/" rel="noreferrer" target="_blank">https://answers.launchpad.<wbr>net/</a>)<br>
* the ubuntu-users mailing list<br>
* the Ubuntu documentation (<a href="https://help.ubuntu.com/" rel="noreferrer" target="_blank">https://help.ubuntu.com/</a>)<br>
* and MANY other mailing lists.<br>
<br>
To limit to ONE source for answers really does not help. At all. And it<br>
is not even the most important source for bugs/issues/support.<br>
<br>
2. Not Bugs<br>
<br>
> Reporting misspells<br>
<br>
But a misspell *is* a bug. Why wouldn't a mispell be reported?<br>
<br>
3. Reporting windowed aplications<br>
<br>
> In the Terminal application enter:<br>
><br>
> ubuntu-bug -w<br>
<br>
Ah, OK. And then this ubuntu-bug thingie will magically find the bug I<br>
want to report, right? Oh, it will not? what should I do then?<br>
<br>
4. Reporting non windowed applications<br>
<br>
> 1. Using the Synaptic application and the list of common packages,<br>
> determine which software package is the most likely to be affected.<br>
<br>
But synaptic is no longer installed by default. How is a casual user<br>
going to *know* that, and how would this casual user get synaptic<br>
installed? Are there other options? What are they?<br>
<br>
5. Reporting unusable systems<br>
<br>
Now we have, as far as I am concerned, a real issue. As I have already<br>
stated, we do not simply need more bugs, we need *good*, *workable*,<br>
bugs. Our experience with free bug entry was horrible. many of the bugs<br>
entered were unworkable. This was why the free bug entry was removed<br>
from view.<br>
<br>
-x-x-x-x-x-x-x-x-<br>
<br>
This is one reason of why reporting bugs is so complicated. It is not<br>
*easy* to report a bug. Keep in mind that a bug report is a *technical*<br>
report of a software defect.<br>
<br>
If one does not know what a bug is (hint: a bug is a defect in a<br>
program/package), why should one be able to enter *anything* as a bug?<br>
<br>
If one does not know if the bad experience just had is, or is not, a<br>
bug, then one would be better served by going to the community support<br>
areas I pointed above. If necessary, after being helped by somebody else<br>
in the community -- and if determined to be a bug -- then a bug may be<br>
opened. But know, at least, we have a good chance of knowing the correct<br>
package name, and  other important details to be reported.<br>
<br>
Cheers,<br>
<br>
..C..<br>
<br>
<br>
<br>
<br>
<br>--<br>
Ubuntu-quality mailing list<br>
<a href="mailto:Ubuntu-quality@lists.ubuntu.com">Ubuntu-quality@lists.ubuntu.<wbr>com</a><br>
Modify settings or unsubscribe at: <a href="https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality" rel="noreferrer" target="_blank">https://lists.ubuntu.com/<wbr>mailman/listinfo/ubuntu-<wbr>quality</a><br>
<br></blockquote></div></div>