• Bugs are submitted with this status
  • They sometimes lack information and 
  • Vast majority of the time have not been triaged (looked at)
  • It is common for users to set the bug back to New from Incomplete after answering questions


  • If you have to ask the reporter questions, set the bug to Incomplete 
  • Ask the submitter to provide any necessary information in a comment, and make sure you subscribe yourself to the bug report so you will get any updates to the bug via e-mail. 
  • In the event that a bug has been in the "Incomplete" state for more than 4 weeks, meaning it has not received a response to a request for more information, please send a gentle reminder with something like:
  • We'd like to figure out what's causing this bug for you, but we haven't heard back from you in a while. Could you please provide the requested information? Thanks!
    If, after an additional 2 weeks, the reporter still hasn't responded and there is no way someone can work with the bug, the bug status should be changed to "Invalid" with a comment similar to:
    We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!

Won't fix

  • This status is sometimes used when the bug fix is too controversial 
  • It is most often used for bugs for bugs on older (and unsupported) versions of software
  • It may also be used for feature requests that the developers do not want to implement (those items should STILL be marked as wishlist)


  • This status should be used when the bug report does not contain adequate information to determine whether or not it is a bug even if it is resolved for the reporter
  • This should also be used if the reported problem is not a bug at all, but for example user error
  • It should be used conservatively as bugs marked as Invalid no longer show up in default searches
  • Be sure to triple-check a bug before you invalidate it


  • Another reporter has experienced the same bug, this can come in the form of a duplicate bug or a bug comment, or...
  • If a triager believes it is very likely that Mythbuntu or MythTV has the described issue
  • Confirmed bugs require confirmation from someone other than the original reporter
  • This helps ensure that the bug is applicable to Ubuntu in general, and not a problem with the reporter's system, therefore...
  • Please don't confirm your own bugs!


  • A member of Mythbuntu bug team or UbuntuBugControl believes that the report describes a genuine bug in enough detail that a developer could start working on a fix
  • Use this when you are confident that it should be looked at by a developer and has enough information

In progress

  • If you are working on fixing a bug, set it to In Progress so people know what's going on
  • In Progress bugs should be assigned to the person working on them

Fix committed

  • Mythbuntu bug task: the changes are pending and to be uploaded soon (it's what PENDINGUPLOAD was in Bugzilla)
    • Fix Committed is also used when an updated package exists in a -proposed repository i.e. hardy-proposed
    • Fix Committed is not to be used when a patch is attached to a bug
  • Upstream (MythTV or myth-plugins) bug task: the fix is in CVS/SVN/bzr or committed to some place

Fix released

  • Mythbuntu bug task: a fix was uploaded to an official Ubuntu repository
    • N.B. This does not include -proposed i.e. hardy-proposed
    • Please don't hesitate to add a changelog as a comment, so people know in which package version a bug was fixed
    • If a bug is fixed in the current development release, it is Fix Released. If the bug also needs to be fixed in a stable release, use the "Target to release" link to nominate it for that release.
  • Upstream bug task: a release tarball was announced and is publicly available


In short, ALWAYS take a best guess at importance.


The default importance for new bugs. It means that there is not sufficient information to determine its importance or it has not been looked at.


A request to add a new feature to one of the programs in Ubuntu.
  • 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
  • Some wishlist items may get marked as invalid simply because there is no foreseeable chance that they will be worked on. If someone has free time, they can search the bug database for Invalid + Wishlist to find such items


Bugs which affect functionality, but to a lesser extent than most bugs, examples are:
  • Ones that can be easily worked around
  • Ones that affect unusual configurations or uncommon hardware
  • A bug that has a moderate impact on a non-core application
  • A cosmetic/usability issue that does not limit the functionality of an application


  • A bug that has a moderate impact on a core application.
  • A bug that has a severe impact on a non-core application.
  • A problem with a non-essential hardware component (network card, camera, webcam, music player, sound card, power management feature, printer, etc.)


  • 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, laptop built-in wireless, video card, keyboard, mouse)
  • Has a moderate impact on a large portion of Ubuntu users (estimated)


A bug which has a severe impact on a large portion of Ubuntu users

(adapted from and