<> ||<>|| == Common Tasks of Bugsquad == Here we have a list of common tasks performed by BugSquad members. Feel free to jump in with whatever looks interesting. For a more detailed explanation of what is involved in triaging, please see [[https://wiki.ubuntu.com/Bugs/HowToTriage|How To Triage]]. If you have any more specific questions don't hesitate to join #ubuntu-bugs on [[IRC]] (irc.freenode.net) and give a shout. === Finding the proper source package === Assigning bugs to packages helps direct bug reports to the developer(s) most likely to be able to help. By ensuring that this information is accurate, you can increase the chances of the bug being fixed promptly. Often, it is unclear which package contains the bug, and in these cases it is appropriate to file the bug in {{{Ubuntu}}}. If a bug is assigned to a package which is clearly not correct, and you don't know the correct package, change it to {{{Ubuntu}}}. Some hints on finding the right package can be found in [[Bugs/FindRightPackage]]. === Confirming problems === If a bug is marked as New, it is helpful for you to try to reproduce the problem, and record the results in Launchpad. If you are able to confirm the problem, you may change the status to Confirmed. If you are unable to confirm the problem, that is also useful information which should be recorded in a comment. When confirming the bug be sure to indicate which version of the package you used. One way to get the package version is via {{{dpkg -l $pkgname}}} where {{{$pkgname}}} is the name of the package you are testing. '''Note:''' Do not confirm your own bugs - confirmation is required from someone other than the original reporter. === Forwarding bugs upstream === You should forward bugs to the authors of the software (upstream), if: * You made sure that the bug doesn't occur because of Ubuntu related changes, * The bug report is complete. To learn how to do this, please consult [[https://wiki.ubuntu.com/Bugs/HowToTriage#Forwarding%20upstream|HowToTriage/ForwardingUpstream]] === How to deal with Feature Requests === If you feel that the bug reported is a non-trivial feature request disguised as a bug report, please introduce the reporter gently to the Specification Process we have. Be sure to mention the following specification resources; FeatureSpecifications, SpecSpec, [[SpecTemplate]] and http://launchpad.net/specs === How to deal with Support Requests === If you feel that the bug reported is a support request disguised as a bug report, please gently introduce the reporter to the Support Tracker located at http://answers.launchpad.net/ubuntu/ . === How to deal with suggestions for changing defaults === If you feel that the bug reported is a suggestion for changing defaults disguised as a bug report, please kindly reroute the discussion to an appropriate mailing list or a discussion forum. If this has already been discussed and rejected, explain the reasons to the user and direct them to the corresponding discussion for further suggestions/comments. === Duplicates === Many of the reports filed against Ubuntu are actually duplicates of bugs already reported. This can happen after a high profile bug has been introduced into Ubuntu, causing a lot of users to report it. Other times, reporters don't know how to check if the same bug has already been filed, or it is hard for them to determine if their bug is the same as another. Finding these duplicate bugs and aggregating information in one bug report is a very valuable contribution. Bugs are duplicates when they have the same root cause. Determining this is a skill that you'll pick up as you become more familiar with a particular package or subsystem. Bugs are ''not'' necessarily duplicates if they have the same effects. For example, many different bugs can cause X not to start. Determining which bug a particular report refers to is part of triaging. If in doubt, ask for a second opinion. It is probably also sensible to ask the reporter to take look at the possible duplicate and to help with the decision. Reporters are normally interested in helping with their own bug reports! '''For the above reason, bugs filed on the "linux" package should not be marked as duplicates.''' When you first look at a new bug, try to find an existing bug in the system that describes the new one. Here's how: * Click the "List open bugs" link at the bottom of the bug page '''or''' * Click the "Bugs" tab at the top of the page * Both ways will produce a list of bugs about the same package * Look for bugs with similar descriptions or related titles. * If they describe the same root cause, decide which report should be the primary one. This should be the one that's the most understandable and contains the most information, not necessarily the oldest (lowest numbered) bug. * For the other report, add a comment like this standard reply <> * Then click the "Mark as Duplicate" link at the top left of the bug report page, and enter the number of the primary bug. By default, searches in Launchpad and mentioned 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 an "Advanced Search". There is also a standardized tag for bugs 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 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 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 a master bug and marking another bug as a duplicate of it, please ask in the IRC Channel of the Bug Squad (#ubuntu-bugs). === Reminder of the Code of Conduct === Note that the Code of Conduct applies to conversations in bug reports too. So if you observe people being disrespectful, please direct them to http://www.ubuntu.com/community/conduct === Setting Status === <> === Setting Importance === <> === Milestone === Don't change this field unless specifically instructed by a developer. In particular, do NOT use this field to record the release of Ubuntu in which the bug was observed: that is not its purpose! It is used by the release team when there is a reason to address the bug in a specific milestone release. === Old Bugs === In many cases bugs reported in earlier versions are still open in our bug tracking system. They may have been fixed upstream without it being noted in Launchpad or the design may have changed so that the issue is no longer relevant. If the bug does not represent a security issue or is otherwise critical, it is very unlikely that the fix will be back-ported to older versions of Ubuntu. When it is fixed in the development branch it is therefore most appropriate to mark it 'Fix Released'. This helps clear the bug tracking system for old cruft. ---- Back to '''[[HelpingWithBugs]]'''.<
><
> [[CategoryBugSquad]]