[Community Help Wiki] Update of "ReportingBugs" by penalvch

[Help Ubuntu]

Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Community Help Wiki" for change notification.

The "ReportingBugs" page has been changed by penalvch:
http://help.ubuntu.com/community/ReportingBugs?action=diff&rev1=288&rev2=289

Comment:
1) Clarified duplicate statement. 2) Misc. minor fixes.

  == All bug reports ==
  
   * '''Please do not file bug reports about End-of-Life operating systems.''' <<BR>> This includes release of Ubuntu, and alternative operating systems. Expecting Ubuntu to provide interoperability with an insecure, end-of-life operating system is simply irresponsible, and inconsiderate of the finite resources of the Ubuntu Community. Information regarding supported Ubuntu releases are available [[https://wiki.ubuntu.com/Releases|here]]. Please see the website of the vendor of the operating system for EOL and support information.
-  * '''Please do not speculate on what you think is or isn't a duplicate report.''' <<BR>> For example, "I googled around and found bug report number..." This is largely unhelpful as it tends not to be a duplicate, and already has been or easily done by triagers and developers. Instead, if you are the original reporter, ensuring the report has all the requested testing information performed would be the fastest way to ensure your bug is resolved as soon as possible. If you are not the original reporter, it's best to file a new report, so that necessary debugging attachments are reviewed. It is a common misconception that filing a potential duplicate report is wasteful. Filing a new report is quite helpful, and is preferred to ease triaging.
+  * '''Please do not speculate on what you think is or isn't a duplicate report''' <<BR>> The exception to this is you are a developer, know specifically where in the code the problem is, and would be submitting a patch to fix the issue. However, noting things like, "I checked Google and found bug report number...", "Why should I file a new report when this is a duplicate?" is largely unhelpful as it tends not to be a duplicate, and already has been or easily done by triagers and developers. Instead, if you are the original reporter, ensuring the report has all the requested testing information performed would be the fastest way to ensure your bug is resolved as soon as possible. If you are not the original reporter, it's best to file a new report, so that necessary debugging attachments are reviewed. It is a common misconception that filing what one initially believes to be a potential duplicate report is not helpful. Filing a new report is quite helpful, and is preferred to ease triaging and development.
   * '''Please do not quote Wikipedia and other non-primary resource information as fact on [[Launchpad]].'''
-  * '''Please do not complain because someone sent what one perceives to be a automated or "canned" response'''. <<BR>> If the response is asking you to do something that you have't done (ex. test the latest development release, file a new report, etc.) do it, as it would get you closer to having your bug fixed faster. Complaining about this is inconsiderate of the Ubuntu triagers and developers who are saving time in comparison to hand typing every single character in an e-mail that goes out their inbox.
+  * '''Please do not complain because someone sent what one perceives to be a automated or "canned" response'''. <<BR>> If the response is asking you to do something that you haven't done (ex. test the latest development release, file a new report, etc.) do it, as it would get you closer to having your bug fixed faster. Complaining about this is inconsiderate of the Ubuntu triagers and developers who are saving time in comparison to hand typing every single character in an e-mail that goes out their inbox.
   * '''Please test the latest version of the package that is considered responsible for the problem.''' <<BR>> For bugs in the [[https://launchpad.net/ubuntu/+source/linux|Linux (Ubuntu)]] package, unless the upstream maintainer or kernel developer notes otherwise, if a new mainline kernel comes out, and you haven't tested with it, you run the strong risk of it not being attended to upstream.
   * '''Please do not post comments such as “Me too!”, “+1”, “bump”, “same here”, etc.''', as it is largely unhelpful, produces spammy e-mail traffic to everyone subscribed to the report, and quite often turns out not to be the same root cause. Instead, please follow the below mentioned procedures.
   * '''Please do not post URLs of requested information.''' <<BR>> For example, links to pastebin.com, paste.ubuntu.com, dropbox.com, etc. If a triager or developer asks you for some information on reproducing or testing, please do not make them dumpster dive by just posting a URL, or saying you already did something in some other report. Instead, put the full reproduction or testing results into the report itself, uncompressed and untarred, and if you have to, then post the link.
   * '''Please do not stack multiple issues into one report'''. <<BR>> For example, jamming suspend and hibernate into one report, reporting multiple [[https://wiki.ubuntu.com/Hotkeys/Troubleshooting|hotkey]] problems into one report (ex. Fn+F3 doesn't turn off my laptop WiFi, Fn+Right doesn't turn the brightness on my [[https://wiki.ubuntu.com/Kernel/Debugging/Backlight|backlight]] down, my brightness settings are not remembered after reboot, etc.). Please make one report for each individual problem.
-  * '''Please do not complain about how long it takes to fix a bug.''' <<BR>> This goes along with saying things like severity of your bug is high so it should be fixed immediately, “I cannot believe it’s not fixed…”, XYZ person(s) do not care about fixing bugs, etc. Especially, if you have not followed the directions mentioned in this article, let alone contributed code upstream. This type of behavior is unconstructive, irritating to others who read your e-mail, and spammy. We all want to see every bug fixed as soon as possible! Naturally, bugs being fixed is limited to reproducibility and clarity of the bug report, the actual impact the bug has on the community, and available developer resources.
+  * '''Please do not complain about how long it takes to fix a bug.''' <<BR>> This goes along with saying things like severity of your bug is high so it should be fixed immediately, “I cannot believe it’s not fixed…”, XYZ person(s) do not care about fixing bugs, etc. Especially, if you have not followed the directions mentioned in this article, let alone contributed code upstream. This type of behavior is nonconstructive, irritating to others who read your e-mail, and spammy. We all want to see every bug fixed as soon as possible! Naturally, bugs being fixed is limited to reproducibility and clarity of the bug report, the actual impact the bug has on the community, and available developer resources.
   * '''Please keep the bug report as objective as possible.''' <<BR>> It is desired for you to provide a fact based, technical impact statement on you, your environment, and the potential or actual impact on the community at large.
   * '''Please provide all relevant information from [[https://wiki.ubuntu.com/DebuggingProcedures]] when you first report your bug'''. <<BR>> This is one of the top reasons why bugs do not get marked [[https://wiki.ubuntu.com/Bugs/Status|Triaged]], as the minimum requirements for triaging, and dealing with the problem by a developer are not provided.
   * '''Please avoid arguing with triagers and developers.''' <<BR>> If a triager or developer asks you to provide information, just provide the information as requested. An example of this is claiming exemption because you or someone else filed a bug report upstream or downstream (which is publicly viewable, and has no restrictions on who can file). You are being asked for this information so that it would provide more information on how to fix the problem. Also, not everyone has access to the hardware you are reporting against, or reproduce the problem as advised in the report. Having you provide the information helps eliminate the difficulty in fixing your bug. If you have a strong disagreement with what a triager or developer is asking of you, please resolve it with them directly via personal message, not on the bug report. This avoids turning a bug development report into a “let’s talk about talking about the problem” tangent, distracting from having your bug solved. The Ubuntu community takes a favor to objective, technical discourse.
@@ -288, +288 @@

   * '''Please do not compress attachments when posting them to a bug report.''' <<BR>> Launchpad doesn't have the same attachment size restriction as other bug reporting platforms. Hence, one may attach large files without fear of rejection. While it is appreciated that one is being considerate and efficient regarding reducing network bandwidth traffic, and storage requirements, this is counteracted by hindering the speed with which a triager or developer may begin analyzing the logs you provide.
   * '''Please test the latest version of the software from upstream.''' <<BR>> Testing the latest upstream release helps in finding out if the issue is a downstream (Ubuntu) issue, or an upstream one as well. If an upstream, then they may also be engaged in seeking support for the problem.
   * '''Please check to see if you problem is a regression.''' <<BR>> If your bug is a regression, it is most helpful to have it bisected. If it is a linux kernel issue, one would consult the article on [[https://wiki.ubuntu.com/Kernel/KernelBisection|bisection]]. Report your bisect results in the report.
-  * '''Please do not run apport-collect more than once per release tested.''' <<BR>> For example, if you originally reported a bug in Trusty via Apport, and then could reproduce it in Utopic, only run apport-collect once in Trusty. This minimizes unnecessary E-Mail traffic to those subscribed to your report and keeps the report efficient.
+  * '''Please do not run apport-collect more than once per release tested.''' <<BR>> For example, if you originally reported a bug in an earlier release via Apport, and then could reproduce it a later release, only run apport-collect once in the earlier release. This minimizes unnecessary email traffic to those subscribed to your report and keeps the report efficient.
  
  == Hardware bug reports (linux kernel, xorg, sound, etc.) ==
  
@@ -302, +302 @@

  "It's Ubuntu's job to provide me a way to update my computer's buggy and outdated BIOS, so I'm not updating."
  }}} The responsibility to keep the BIOS updated lies solely with owner of the hardware. However, as a courtesy to the Ubuntu Community, update methods that may not have been offered by your BIOS vendor are available [[https://help.ubuntu.com/community/BiosUpdate|here]]. <<BR>><<BR>> {{{
  "Updating my computer's buggy and outdated BIOS is risky."
- }}} Everything one does with any operating system, application, or hardware has some level of risk, from upgrading software (upgrade breaks functionality or security), to servicing hardware (static electricity, accidently bend/break the hardware, etc.). However, one simply eliminates or largely minimizes these risks with common sense techniques. In the case of a BIOS update, one ensures the power supply is not interrupted during the upgrade. As well, one may contact their computer vendor for further advice. <<BR>><<BR>> {{{
+ }}} Everything one does with any operating system, application, or hardware has some level of risk, from upgrading software (upgrade breaks functionality or security), to servicing hardware (static electricity, accidentally bend/break the hardware, etc.). However, one simply eliminates or largely minimizes these risks with common sense techniques. In the case of a BIOS update, one ensures the power supply is not interrupted during the upgrade. As well, one may contact their computer vendor for further advice. <<BR>><<BR>> {{{
  "I don't feel like updating my computer's buggy and outdated BIOS."
  }}} This is not respecting the additional effort triagers and developers would have to put in to not only look at the code to see if it is correct (which is difficult enough), but to also think of all the ways a non-compliant BIOS could manifest problems given the code change.
   * '''One report, per person, per hardware combination, per bug'''. <<BR>> Many [[https://launchpad.net/ubuntu/+source/linux|Linux]] package, hardware, and other non-user space bugs are hardware dependent on both the hardware itself, and what other hardware the problematic hardware is connected to. For more on this please see [[https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue|here]], and further below in this article.