[Ubuntu Wiki] Update of "Bugs/HowToTriage" by dholbach

[Ubuntu Wiki]

Dear Wiki user,

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

The following page has been changed by dholbach:
http://wiki.ubuntu.com/Bugs/HowToTriage?action=diff&rev1=116&rev2=117

------------------------------------------------------------------------------
  
  Every bug report is a conversation with the reporter.  The first contact any reporter usually has with the Ubuntu community is through a bug triager, who tries to put together a complete bug report.  It's very important that we give a good impression, so please be polite and try to use your best English.
  
- Starting with working on simple, untriaged bugs is a good way to get acquainted with the procedure because you'll have to deal with every aspect of the life cycle of a bug. The section [[https://wiki.ubuntu.com/Bugs/HowToTriage#Untriaged bugs|Untriaged bugs]] explains where to find them.
+ Starting with working on simple, untriaged bugs is a good way to get acquainted with the procedure because you'll have to deal with every aspect of the life cycle of a bug. The section [[HowToTriage#Untriaged bugs|Untriaged bugs]] explains where to find them.
  
  = Bug types =
  
@@ -27, +27 @@

  
  In Feisty and early Gutsy, those bugs were public, so that everyone could see them. This created a privacy problem, though, since core dumps and stack traces could contain potentially sensitive information. Also, crash reports generate a lot of bug mail noise. With the automatic duplicate checking, a fair amount of the reported bugs are completely irrelevant for triagers.
  
- Since Gutsy, these problems [[https://wiki.ubuntu.com/CrashReporting|have been mitigated]]: bugs are filed with the "private" flag enabled, i. e. only the reporter and subscribers can see it. The reprocessing bots will subscribe the `ubuntu-bugcontrol` team, but without sending bug email to the team members.
+ Since Gutsy, these problems [[CrashReporting|have been mitigated]]: bugs are filed with the "private" flag enabled, i. e. only the reporter and subscribers can see it. The reprocessing bots will subscribe the `ubuntu-bugcontrol` team, but without sending bug email to the team members.
  
  Thus crash bugs differ from other bugs in two important aspects: they need to be checked for sensitive data, and there will not be any initial bug mail for them until they become public. Triagers should check the following things:
  
@@ -123, +123 @@

    * Main inclusion report (MIR)
    
   Bugs in this category will have '''any''' of the following teams subscribed:
-   * [[https://bugs.launchpad.net/~ubuntu-universe-sponsors/|Ubuntu Universe Sponsors]]
-   * [[https://bugs.launchpad.net/~ubuntu-main-sponsors/|Ubuntu Main Sponsors]]
+   * [[https://bugs.launchpad.net/~ubuntu-sponsors/|Ubuntu Sponsors]]
    * [[https://bugs.launchpad.net/~ubuntu-archive|Ubuntu Package Archive Administrators]]
    * [[https://bugs.launchpad.net/~motu-release|MOTU Release Team]]
    * [[https://bugs.launchpad.net/~ubuntu-release|Ubuntu Release Team]]
    * [[https://bugs.launchpad.net/~ubuntu-mir|MIR approval team]]
  
- For packages in Universe/Multiverse, please see [[https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue|Sponsors Queue]] page for more details.
+ For packages in Universe/Multiverse, please see [[MOTU/Sponsorship/SponsorsQueue|Sponsors Queue]] page for more details.
  
  === Needs Packaging Bugs ===
  
  A ''needs-packaging'' is, a subset of the Developer Process bugs above: it is not really a bug, but a request to add a new package to Ubuntu. You may find them with a subject like: {{{[needs-packaging] <package>}}}, or with either the description or summary requesting that a package be created. These bugs are used to track software requested for inclusion in Ubuntu. For these bugs, please:
  
-   * read and follow the instructions on [[https://wiki.ubuntu.com/MOTU/Sponsorship/SponsorsQueue|SponsorQueue]]. A summary follows:
+   * read and follow the instructions on [[MOTU/Sponsorship/SponsorsQueue|SponsorQueue]]. A summary follows:
    * '''check''' to see if it is already in Ubuntu (see http://packages.ubuntu.com, or run {{{rmadison <package>}}}): if it is already in the archives, then mark it as ''Invalid'', and add a comment explaining your action;
    * if '''not''' in Ubuntu, then check Debian (see http://packages.debian.org, or run {{{rmadison -u debian <package>}}}). If it is in Debian, mark it as ''Invalid'', and add a comment stating:
  {{{
@@ -239, +238 @@

  The default searches in Launchpad and used above will only look at {{{Open}}} bugs. It may also be worthwhile to go through the list of {{{Invalid}}} and {{{Won't Fix}}} bugs which you can look for by using the "Advanced Search". There is also a standardized bug tag for ones likely to have lots of duplicates -- [[https://launchpad.net/ubuntu/+bugs?field.tag=metabug|metabug]].
  
  When marking a bug report as a duplicate of another (master) bug report, please also check whether the master bug report is marked as a private. If so, the master bug report might not be visible to the current bug reporter. When the parent bug is indeed marked as private please check why it is so. If it's only private because apport makes all bugs private by default, but the coredump has been removed and none of the apport attachments contain anything private, it may be made public. If it does contain confidential information, the bug should remain as private and it is better to search for another bug which could be safely marked as the master bug. For any guidance regarding the private status of master bug and marking another bug a duplicate of it, please ask in the IRC Channel of the Bug Squad (#ubuntu-bugs). 
- For more information on private Apport bugs, have a look at the [[https://wiki.ubuntu.com/Bugs/HowToTriage#Apport crash reports|Apport crash reports]] section.
+ For more information on private Apport bugs, have a look at the [[Bugs/HowToTriage#Apport crash reports|Apport crash reports]] section.
  
  ----
  CategoryBugSquad