<<Include(Bugs/BugsHeader)>>

=== You're probably looking for three things from this page: ===

 * If you wish to report a new bug, please see [[Bugs/ReportingBugs|Report a Bug]].
 * If you wish to help categorize (we call this triage) a bug, please see [[Bugs/HowToTriage|Triage a Bug]].
 * If you wish to help fix a bug, please see [[Bugs/HowToFix|Fix a Bug]].


||<tablestyle="width:50%;" style="width: 40px; border: none; -moz-border-radius-topleft: 15px ;-moz-border-radius-bottomleft: 15px; background-color: #F1F1DD;text-align: left;">{{attachment:help.png}}||<style="width: 90%; border: none; -moz-border-radius-topright: 15px;-moz-border-radius-bottomright: 15px; text-align: left; font-size: 1.8em; background-color: #F1F1DD;" >'''What is a Bug?'''||

A software bug is an error or fault in a computer program which makes it fail to work as it's supposed to.  This could be as simple as failing to work at all, or as complicated as a subtly incorrect result.  Nevertheless, we really want to eliminate software bugs, as they make programs less useful.

Some things aren't bugs, but are missing features that should be reasonably included.  Missing features shouldn't be reported as bugs, instead FeatureSpecifications should be written for them.  There isn't a bright line that you can draw between bugs and missing features, but here's a guideline: if it's a problem that would have many details to address, it's likely to be a feature.  For example, the inability to write files safely to a modern OS X partition is a missing feature.  The inability to write files safely to a ReiserFS partition would be a bug.

For an in-depth discussion about bugs, you should check out WikiPedia:Software_bug.

||<tablestyle="width:50%;" style="width: 40px; border: none; -moz-border-radius-topleft: 15px ;-moz-border-radius-bottomleft: 15px; background-color: #F1F1DD;text-align: left;">{{attachment:bugsquad.png}}||<style="width: 90%; border: none; -moz-border-radius-topright: 15px;-moz-border-radius-bottomright: 15px; text-align: left; font-size: 1.8em; background-color: #F1F1DD;" >'''Helping With Bugs'''||

== Bug triage ==

Bug triage is an essential part of Ubuntu's development.

Triaging bugs consists of several things:
 * Responding to new bugs as they are filed.
 * Ensuring that new bugs have all the necessary information.
 * Assigning bugs to the proper package.
 * Confirming bug reports by trying to reproduce them.
 * Setting the priority of bugs reports.
 * Searching for and marking duplicates in the bug tracking system.
 * Sending bugs to their upstream authors, when applicable.
 * Cross-referencing bugs from other distributions.
 * Expiring old bugs.

However, you don't need to do all of those things to help!  Recreating a bug and setting the status to Confirmed is enough.

Bug triage is an excellent way to start helping out.  You get to learn a lot about Ubuntu, its available packages, its infrastructure, and you get a feel for the development pulse.

You can learn how to triage bugs and chip in, just see the [[Bugs/HowToTriage]] page.

== Joining the team ==

The people who work on triaging bugs in Ubuntu are called the Ubuntu BugSquad.  Check out the BugSquad/GettingInvolved page to learn how to join.

You can almost always find members of the Bug Squad in #ubuntu-bugs on the freenode [[IRC]] server who will be happy to answer any questions you have.

== Fixing bugs ==

If you've got an interest in  delving deep into bugs, we'd love to have you help fix bugs.  Each package you install in Ubuntu gets built from a source package.  Each source package has a page devoted to its bugs.

For instance, the bug page for the {{{hello}}} package is at: [[https://launchpad.net/ubuntu/+source/hello/+bugs]].

You don't have to know how to program to fix bugs, but it certainly helps!  There are some simple things that anyone can do.  For starters, many bugs involve typos or documentation problems, which anyone can fix.  If you can write in another language, there are plenty of translation errors you can solve.  For functionality problems, you can try to track down a fix by the upstream authors of a package.  Or find a fix that was included in another distribution.

You can learn more about fixing bugs by reading the [[Bugs/HowToFix]] page.


||<tablestyle="width:50%;" style="width: 40px; border: none; -moz-border-radius-topleft: 15px ;-moz-border-radius-bottomleft: 15px; background-color: #F1F1DD;text-align: left;">{{attachment:information.png}}||<style="width: 90%; border: none; -moz-border-radius-topright: 15px;-moz-border-radius-bottomright: 15px; text-align: left; font-size: 1.5em; background-color: #F1F1DD;" >'''Other Information'''||

 * The [[BugSquad|BugSquad]] typically runs [[UbuntuBugDay|Hug Days]] on a regular basis, this is a great way to work with people and learn by getting your hands dirty right away.
 * Sometimes bugs are with the software that we ship with Ubuntu. We must ensure that those bugs get reported to upstream - [[Bugs/Upstream|Working with Upstream Projects]]
 * How are we doing? Check out some [[Bugs/Stats|Bug Statistics]].
 * Want to do a little everyday? Join the [[5-a-day|5-a-day team]] to keep Ubuntu healthy!
 * [[Bugs/CommonTasks]] explains different tasks, which are done in the world of bugs every day.
 * [[Bugs/Status]] how Ubuntu uses the Status field
 * [[Bugs/Importance]] how Ubuntu uses the Importance field 
 * [[Bugs/Responses]] has a list of common responses for the most common type of bugs.
 * [[Bugs/Examples]] show examples of bugs and how they were resolved.
 * [[Bugs/Teams]] introduction to the different workflows of different teams
 * [[Bugs/Debian]] for specific information about sharing bugs/patches with Debian
 * [[DebuggingProcedures]] for Ubuntu bugs

----
[[CategoryBugSquad]]