On Tue, May 9, 2017 at 5:58 AM, Alberto Salvia Novella <[email protected]> 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. -- Ubuntu-quality mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-quality
