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 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.
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 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.
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
Include: Nothing found for "^== A duplicate ==$"!
When you update one of these responses, you should also update the response used by the Firefox extension. These responses can be found in the bazaar branch lp:ubuntu-bugcontrol-tools in the file gm-xml-files/bugsquad-replies.xml. To check out a branch, use
bzr branch lp:ubuntu-bugcontrol-tools
Only members of bug-control can commit to this branch. But you can submit a merge proposal, Brian Murray will review/merge it (see this email message), and they can be used when replying to a bug report if merged.
Not described well
Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately, we cannot work on this bug because your description didn't include enough information. You may find it helpful to read "How to report bugs effectively" http://www.chiark.greenend.org.uk/~sgtatham/bugs.html. We'd be grateful if you would then provide a more complete description of the problem.
We have instructions on debugging some types of problems at http://wiki.ubuntu.com/DebuggingProcedures
At a minimum, we need:
1. the specific steps or actions you took that caused you to encounter the problem,
2. the behavior you expected, and
3. the behavior you actually encountered (in as much detail as possible).
Missing Steps to Recreate Bug
Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:
* Is this reproducible?
* If so, what specific steps should we take to recreate this bug?
This will help us to find and resolve the problem.
Missing Apport Information
Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command, as it will automatically gather debugging information, in a terminal:
When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.
Package or domain specific questions
The following packages or type of bugs require the specific debugging information:
- 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 -- 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
Include: Nothing found for "Header.*$"!
Include: Nothing found for "^----"!
Ubuntu uses the following guidelines for assigning importance. The importance of the bug signifies the priority that it should be given by people fixing bugs.
In order to set the Importance field of a bug in Launchpad, you need to be a member of UbuntuBugControl either through direct membership or because of your membership in another team. The importance of the bug should be set as soon as possible.
The importance of a bug report can be modified by clicking on the current Status or Importance, in the yellow line and under the "Affects" column header, which will reveal a sub menu. You can then choose a new importance in the drop down box.
Here are the meanings of the different importance values:
Undecided: The default for new bugs. Also means that there is insufficient information to determine importance.
Wishlist: Missing functionality.
- These aren't always bugs, but can be ideas for new features which do not yet exist.
- These can also be requests to have software packaged for Ubuntu.
If it is non-trivial to implement, it should rather be written as a feature specification, see FeatureSpecifications.
- These can be bugs that affect an experimental extension or non-essential feature of a given package/project.
Bugs that would only be fixed on a best-effort or outside-contribution basis might also be considered wishlist.
Low: Bugs which affect functionality, but to a lesser extent than most bugs, examples are:
Bugs that have easy work-arounds
- Bugs that affect unusual end-user configurations or uncommon hardware
- Bugs that affect a non-essential aspect and limited scope of the application
- Bugs that have a moderate impact on a non-core application
- Cosmetic/usability issues that does not limit the functionality of a non-core application
- Non-ideal default configurations
Medium: Most bugs are of medium importance, examples are:
- A bug that has a moderate impact on a core application.
- A bug that has a severe impact on a non-core application.
- A bug which impacts accessibility of a non-core application.
- A usability issue that does not limit the functionality of a core application.
- A problem with a non-essential hardware component (removable network card, camera, webcam, music player, sound card, power management feature, printer, etc.)
High: A bug which fulfills one of the following criteria:
- Has a severe impact on a small portion of Ubuntu users (estimated)
- Makes a default Ubuntu installation generally unusable for some users
- For example, if the system fails to boot, or X fails to start, on a certain make and model of computer
- A problem with an essential hardware component (disk controller, built-in networking, video card, keyboard, mouse)
- Has a moderate impact on a large portion of Ubuntu users (estimated)
- Prevents the application or any dependencies from functioning correctly at all
- Renders essential features or functionality of the application or dependencies broken or ineffective
- Impacts accessibility of a core application
Critical: A bug which has a severe impact on a large portion of Ubuntu users
- Causes data corruption
- Crashes the entire operating system
- Renders the system temporarily or permanently unusable
- Severely affects applications beyond the package responsible for the root cause
If you're not yet an Ubuntu Bug Control member, you'll have to ask someone who is to do it for you. Paste the bug number in #ubuntu-bugs channel at FreeNode and say you think the bug should be set to importance 'Wishlist / Low / Medium / High / Critical'. Someone will notice your comment and set it for you, although not necessarily immediately.
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.
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.