[Ubuntu Wiki] Update of "Bugs/Bug statuses" by penalvch
Ubuntu Wiki
noreply at ubuntu.com
Fri Dec 26 02:20:13 UTC 2014
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Ubuntu Wiki" for change notification.
The "Bugs/Bug statuses" page has been changed by penalvch:
http://wiki.ubuntu.com/Bugs/Bug%20statuses?action=diff&rev1=72&rev2=73
Comment:
1) RM'd 2x linefeed prior to Headings as it doesn't make space in presentation. 2) Not all valid reports are bugs (i.e. certain issues that are Wishlist, Opinion, etc.). 3) Misc. presentation fixes.
## page was renamed from BugSquad/ManagingStatus
<<Include(BugSquad/KBHeader)>>
+ A report's status is a reflection of the current development state of what is being reported.
- Bug statuses are a reflection of the current state of a bug report.
+ The status of a report can be modified by clicking on the current status in the yellow line, towards the top of the page. This will reveal a sub menu of statuses to choose from. You can then set a new status via the drop down box.
- The status of a bug report can be modified by clicking on the current status in the yellow line, which will reveal a sub menu. You can then set a new status in the drop down box.
-
- Below is a list of bug statuses, their meaning and when to use them:
+ Below is a list of report statuses, their meaning, and when to use them:
* '''New''':
- * Bugs are submitted with this status,
+ * Reports are submitted with this status.
- * They sometimes lack information '''and'''
+ * They sometimes lack information.
- * All of them should be untriaged
+ * All of them should be untriaged.
* '''Incomplete''':
- * If you have to ask the reporter questions, set the bug to {{{Incomplete}}}
+ * If you have to ask the reporter questions, set the report 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.
+ * When you ask the reporter to provide any necessary information in a comment, and make sure you subscribe yourself to the report so you will get any updates to the report via e-mail.
- * <<Include(Bugs/Responses, , from="^== Incomplete bugs without a response from submitter ==", to="==")>>
- * If anyone, including you, comments on the bug, the 60 day expiration clock is reset.
+ * If anyone, including you, makes a comments, the 60 day expiration clock is reset.
+ * For more on this, please see [[https://wiki.ubuntu.com/Bugs/Responses]].
* '''Opinion''':
- * The status 'opinion' means there is a difference of opinion around a particular bug and people are free to continue the discussion, but the project or package maintainers need to move to other work and are considering the issue closed. The idea is that bugs can be marked closed, so developers aren't wasting time on them, but discussion can still be on-going.
+ * This means there is a difference of opinion around a the report and people are free to continue the discussion, but the project or package maintainers need to move to other work and are considering the issue closed. The idea is that reports can be marked closed, so developers aren't wasting time on them, but discussion can still be on-going.
- * This status 'opinion' is considered an experiment, and will be closely monitored.
+ * This status is considered an experiment, and will be closely monitored.
* '''Invalid''':
- * 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 status should be used when the 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
+ * This should also be used if the reported problem is not a bug at all. For example, user's lack of knowledge on how something works, hardware failure, or fixed after updating a buggy, and outdated BIOS.
- * It should be used conservatively as bugs marked as Invalid no longer show up in default searches
+ * It should be used conservatively as reports marked as Invalid no longer show up in default searches.
- * Be sure to triple-check a bug before you invalidate it
+ * Be sure to triple-check a report before you invalidate it.
* '''Expired'''
- * This status is similar to Invalid, but is meant specifically for bugs that have been Incomplete for too long. (See above.)
+ * This status is similar to Invalid, but is meant specifically for reports that have been Incomplete for too long (see above).
* This status is only able to be set by using launchpadlib or the email interface.
- * Like Invalid bugs, Expired bugs do not show up in default searches.
+ * Like Invalid reports, Expired reports do not show up in default searches.
* '''Confirmed''':
- * Another reporter has experienced the same bug, this can come in the form of a duplicate bug or a bug comment
+ * Another reporter has experienced the same issue. This can come in the form of a duplicate report or a comment.
- * {{{Confirmed}}} bugs require confirmation from '''someone other than the original reporter'''
+ * {{{Confirmed}}} reports 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!
+ * This helps ensure that the report is applicable to Ubuntu in general, and not hardware failure, lack of knowledge, etc.
+ * In general, please don't confirm your own bugs, unless there is a documented exception by the development group of the package (ex. linux).
* '''Triaged''':
- * A member of [[UbuntuBugControl]] believes that the report describes a genuine bug in enough detail that a developer could start working on a fix. ''(also see tip below)''
+ * A member of [[UbuntuBugControl]] believes that the report describes a genuine issue 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
+ * Use this when you are confident that it should be looked at by a developer '''and''' has enough information for the developer to fix it.
- * While not a requirement a bug's Ubuntu task status will be Triaged before any upstream forwarding occurs
+ * While not a requirement, a report's Ubuntu task status should be Triaged before any upstream forwarding occurs.
- * With bugs about '''linux''' Triaged means that the bug has been tested with the upstream mainline kernel
+ * With reports about '''linux''': Triaged means that the original reporter has tested with the latest upstream mainline kernel they can technically test to.
- * For process bugs (e.g. [[FreezeExceptionProcess|FFes]] and [[SyncRequestProcess|syncs]]) triaged means the action has been approved by the relevant developers.
+ * For process reports (e.g. [[FreezeExceptionProcess|FFes]] and [[SyncRequestProcess|syncs]]) Triaged means the action has been approved by the relevant developers.
* '''In Progress''':
- * You have assigned the bug '''to yourself''', and you're going to fix it '''right now''' by submitting a [[https://wiki.ubuntu.com/Bugs/Patches|patch]].
+ * You have assigned the report '''to yourself''', and you're going to address it '''right now''' by submitting a [[https://wiki.ubuntu.com/Bugs/Patches|patch]].
- * This status is not for if one is simply debugging a bug (ex. bisecting, testing out a patch provided by someone else, you have a work around, etc.).
+ * This status is not for if one is simply debugging (ex. bisecting, testing out a patch provided by someone else, you have a work around, etc.).
- * /!\ '''Never''' assign bugs to others.
+ * /!\ '''Never''' assign a report to others.
- * /!\ If there has been an assignee for more than six months without a fix or response, one could unassign him and revert the status.
+ * /!\ If there has been an assignee for more than six months without a fix or response, one could unassign them and revert the status.
* '''Fix Committed''':
- * Ubuntu bug task: the changes are pending and to be uploaded soon (it's what PENDINGUPLOAD was in Bugzilla)
+ * Ubuntu task: the changes are pending, and to be uploaded soon.
- * {{{Fix Committed}}} is also used when an updated package exists in a -proposed repository i.e. hardy-proposed
+ * {{{Fix Committed}}} is also used when an updated package exists in a -proposed repository (i.e. trusty-proposed).
- * {{{Fix Committed}}} is '''not''' to be used when a patch is attached to a bug
+ * {{{Fix Committed}}} is '''not''' to be used when a patch is attached to a report.
- * Upstream bug task: the fix is in CVS/SVN/bzr or committed to some place
+ * Upstream task: the fix is in bzr/CVS/git/SVN, or committed to some place.
* '''Fix Released''':
- * Ubuntu bug task: a fix was uploaded to an official Ubuntu repository
+ * Ubuntu task: a fix was uploaded to an official Ubuntu repository.
- * N.B. This '''does not''' include -proposed i.e. hardy-proposed
+ * N.B. This '''does not''' include -proposed (i.e. trusty-proposed).
- * Please don't hesitate to add a changelog as a comment, so people know in which package version a bug was fixed
+ * Please don't hesitate to add a changelog as a comment, so people know in which package version the fix was released in.
- * If a bug is fixed in the current development release, it is {{{Fix Released}}}. If the bug also [[StableReleaseUpdates | needs to be fixed]] in a stable release, use the "Target to release" link to nominate it for that release.
+ * If the current development release has the fix applied, it is {{{Fix Released}}}. If a [[StableReleaseUpdates|stable release needs to be fixed]] also, use the "Target to release" link to nominate it for that release.
- * Upstream bug task: a release tarball was announced and is publicly available
+ * Upstream task: a release tarball was announced and is publicly available.
* '''Won't Fix''':
- * This status is sometimes used when the bug fix is too controversial
+ * This status is sometimes used when the fix is too controversial.
- * It is most often used for bugs with a release target that will not be fixed in that particular release but may be fixed later
+ * It is most often used for a report with a release target that will not be fixed in that particular release but may be fixed later.
- * It may also be used for feature requests that the developers do not want to implement
+ * It may also be used for feature requests that the developers do not want to implement.
/!\ the following status changes are restricted to members of [[UbuntuBugControl]] or package maintainers:
- * moving to Triaged, or WONTFIX
+ * Moving to Triaged, or Won't Fix.
- * moving ''from'' WONTFIX
+ * Moving ''from'' Won't Fix.
- * targeting to a specific Ubuntu release
+ * Targeting to a specific Ubuntu release.
-
=== Frequently Asked Questions ===
- ''If you have a question, please feel free to ask it by emailing the [[https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad|BugSquad mailing list]] with your question.''
+ ''If you have a question, please feel free to ask it by emailing the [[https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugsquad|BugSquad mailing list]] with your question.''
- * What is the appropriate status if the bug's reporter later says the bug no longer exists but the related changelog does not note a fix?
+ * What is the appropriate status if the original reporter later says the issue no longer exists but the related changelog does not note a fix?
- * See the first point under "Invalid", the bug does not have sufficient information.
+ * See the first point under "Invalid", the report does not have sufficient information.
- * What should a triager do if there is consensus ''among users and developers'' that an issue is valid but there is no good solution?
+ * What should a triager do if there is consensus ''among users and developers'' that an issue is valid but there is no good solution?
- * Keep the bug open with a status of "Wishlist" or "Triaged", depending on the severity.
+ * Keep the report open with a status of "Triaged", and/or mark it with [[Importance]] "Wishlist", depending on the severity.
- * Should the bug reporter reset the bug status to "New" if providing more information to an "Incomplete" bug?
+ * Should the original reporter reset the report status to "New" if providing more information to an "Incomplete" report?
- * Yes.
+ * Yes.
- * When converting a question to a bug, can the bug status immediately be set to "Confirmed" if comments in the question indicate that multiple users experience the bug?
+ * When converting a question to a report, can the status immediately be set to "Confirmed" if comments in the question indicate that multiple users experience the issue?
- * Make a judgment call: as long as ''more than one person'' experiences the bug, the proper status is "Confirmed".
+ * Make a judgment call: as long as ''more than one person'' can reproduce it, the proper status is "Confirmed".
- * What should a triager do if a bug needs more information, including steps to reproduce, but the original reporter is not available to provide it?
+ * What should a triager do if a report needs more information, including steps to reproduce, but the original reporter is not available to provide it?
- * Mark the bug as Invalid with a comment that the reporter should provide the information and reopen the bug by resetting its status to 'New'.
+ * Mark the report as Invalid, with a comment that the reporter should provide the information, and reopen the report by resetting its status to 'New'.
- * What is the appropiate bug status for issues caused by faulty hardware?
- * The appropriate bug status for such issues is "Invalid".
-
- ||<tablestyle="width:90%;" style="width: 35px; border: none; -moz-border-radius-topleft: 15px ;-moz-border-radius-bottomleft: 15px; background-color: #F1F1DD; border: none; -moz-border-radius-topright: 15px;-moz-border-radius-bottomright: 15px; font-size: 1em; text-align: center;">{{attachment:IconHelp2.png}}Not yet an [[https://wiki.ubuntu.com/UbuntuBugControl|Ubuntu Bug Control]] member? If you notice a bug having sufficient information and has not yet been set to Triaged, you'll have to ask someone who is to set the bug to ''Triaged'' for you. Paste the bug number in {{{#ubuntu-bugs}}} channel at [[https://wiki.ubuntu.com/FreeNode|FreeNode]] and say you think the bug should be set to 'Triaged' with importance 'Wishlist / Low / Medium / High / Critical' according to [[Bugs/Importance]]. Someone will notice your comment and set it for you, although not necessarily immediately.||
+ ||<tablestyle="width:90%;" style="width: 35px; border: none; -moz-border-radius-topleft: 15px ;-moz-border-radius-bottomleft: 15px; background-color: #F1F1DD; border: none; -moz-border-radius-topright: 15px;-moz-border-radius-bottomright: 15px; font-size: 1em; text-align: center;">{{attachment:IconHelp2.png}}Not yet a [[https://wiki.ubuntu.com/UbuntuBugControl|Ubuntu Bug Control]] member? If you notice a report having sufficient information and has not yet been set to Triaged, you'll have to ask someone who is to set the report to ''Triaged'' for you. Paste the report number in {{{#ubuntu-bugs}}} channel at [[https://wiki.ubuntu.com/FreeNode|FreeNode]] and say you think the report should be set to 'Triaged' with importance 'Wishlist / Low / Medium / High / Critical' according to [[Bugs/Importance]]. Someone will notice your comment and set it for you, although not necessarily immediately.||
-
----
CategoryBugSquad
More information about the Ubuntu-bugsquad
mailing list