Issues

An issue in Google Issue Tracker is a bug report, feature request, change request or process workflow item that a user wants to track or expects another user or team to track. Issues are organized in components, each of which contains a group of related issues. Each issue in Issue Tracker has its own details page where users track activity on the issue, and where users make comments and update the issue data.

Issue fields

Each issue has a set of associated fields that describe it and its current state. This includes the type of issue, its importance in terms of severity and priority, and the record of activity on the issue. Some fields are common to all issues. Issue Tracker also supports custom fields that are available only when an issue is associated with a specific component. For all new issues, there are several required fields. These include Component, Title, Priority and Type. Some components also have custom fields that are required.

On an issue details page, most fields are found on the right side of the page in the Issue Fields panel. Some additional fields reside in the Related Issues tray near the top of the page. Nearly all fields are editable in Issue Tracker by clicking on the link, drop-down list or pencil icon associated with them. When you hover over a field, Issue Tracker provides brief information on the field in mouseover text.

For a description of default issue fields, see Glossary of Fields.

Issue type

The Type field allows you to categorize issues within a component in one of several common groups. This field is required. The following table shows the possible issue types:

Issue Type Description
Bug Behavior is counter to what is supposed to occur or was documented to occur, or the product does not work as expected.
Feature Request Product works as intended, but could be improved through the specified changes.
Customer Issue Issue is affecting a third party and may not be reproducible by the person reporting the issue. Such an issue may be simply a matter of troubleshooting or training, but may turn out to be a bug or feature request.
Internal Cleanup Issue has no outward effect on the behavior of a product, but addressing the issue will allow for more streamlined and/or intuitive interaction when developing the product. You can also use this type to track maintenance issues.
Process Process is a miscellaneous category that has varying uses depending on the project. For example, you can use this type for issues that are generated by an API, or use it to track administrative tasks.
Vulnerability Privacy and security vulnerabilities subject to SLOs defined by Google's privacy and security guidelines. Read-only until after 2017-11-01.

Issue priority

The Priority field allows you to specify the importance of an issue. This field is required. Teams generally have different criteria for how importance of an issue is determined. The following table shows a common way of prioritizing issues:

Issue Priority Description
P0 An issue that needs to be addressed immediately and with as many resources as is required. Such an issue causes a full outage or makes a critical function of the product to be unavailable for everyone, without any known workaround.
P1 An issue that needs to be addressed quickly. Such an issue significantly impacts a large percentage of users; if there is a workaround it is partial or overly painful. The impact of the issue is to a core organizational function, or fundamentally impedes another team.
P2 An issue that needs to be addressed on a reasonable timescale. Such an issue could be any of the following: 1) An issue that would be P0 or P1 but has a reasonable workaround, 2) An issue that is important to a large percentage of users and is connected to core organizational functions, 3) An issue that is an impediment to the work of other teams and has no reasonable workaround. P2 is especially relevant for first-use or install-time issues and is the default priority level.
P3 An issue that should be addressed when able. Such an issue is relevant to core organizational functions or the work of other teams, but does not impede progress or else has a reasonable workaround.
P4 An issue that should be addressed eventually. Such an issue is not relevant to core organizational functions or the work of other teams, or else it relates only to the attractiveness or pleasantness of the system.

Issue status

The Status field allows you to specify the status of an issue in the resolution process. Teams generally have different definitions of what activities need to occur for an issue to change status or be resolved. Not all available Status field values need to be used to track the resolution of an issue. The following table shows common ways of using the Status field:

Issue Status Description
New The issue does not have a person or group currently assigned to it.
Assigned The issue has a person assigned to it. That person appears in the Assignee field.
Accepted The assignee has acknowledged the issue and has begun work on it.
Fixed The issue has been addressed.
Fixed (Verified) The issue has been addressed and the correctness of the fix has been confirmed.
Won't Fix (Not reproducible) There is either not enough information to fix the issue, or the issue as reported cannot be re-created.
Won't Fix (Intended behavior) The issue describes the expected behavior of the product under the reported circumstances.
Won't Fix (Obsolete) The issue is no longer relevant due to changes in the product.
Won't Fix (Infeasible) The changes that are needed to address the issue are not reasonably possible.
Duplicate The issue has been reported elsewhere. To set an issue's status to Duplicate, see Duplicate an Issue.

Issue Tracker considers issues as being either Open or Closed depending on their status. Open issues are those that are awaiting resolution. This includes any issue with a status of New, Assigned, or Accepted. Closed issues are those that require no further action, except possibly verification. This includes any issue with a status of Fixed, Won't Fix, or Duplicate.

Status icons

Status icons are a visual representation of the status of an issue. A status icon apears to the left of an issue that is in the Blocked By or Blocking drop-down list of another issue. These icons provide a quick way to assess the progress of a blocked or blocking issue without having to leave the current page. You can also set the Status column of a search results page to display status icons instead of status text.

Quick-change status

There are two ways to quickly change the status of an issue in order to advance it to the next typical step in the resolution process. The first is the Change Status button, located in the App Bar near the top of the issue details page, and the Change Status link in the Issue Fields panel on the right-hand side of the page. Clicking either will advance the status of the issue as follows:

  • If the issue is new and unassigned, or if the assignee is someone other than yourself, the quick-change prompt reads Take Issue. Quick-changing the status will set the assignee to you and, if currently set otherwise, change the status of the issue to Assigned.

  • If you are the assignee of an issue and its status is Assigned, the quick-change prompt reads Start work. Quick-changing changes the status of the issue to Accepted.

  • If you are the assignee of an issue and its status is Accepted, the quick-change prompt reads Mark Fixed. Quick-changing changes the status of the issue to Fixed.

  • If an issue has a status of Fixed and you are the verifier, the quick-change prompt reads Verify. Quick-changing changes the status of the issue to Fixed (Verified).

  • If an issue has a closed status (Fixed, Duplicate or Won't Fix), the quick-change prompt reads Re-open (except in the case mentioned above). Quick-changing changes the status to either New (if no one had been listed as the assignee) or Assigned, with the current assignee retained.

Editing issues

If you have View and Edit permission for a component, you can edit its fields as well as append comments to it. Some fields, however, cannot be edited at all, such as the issue creation date or comments that have previously been made.

Edit levels

Changes to an issue have varying level of significance that determine whether the changes appear in the history panel for the issue and whether users receive e-mail notification when the change occurs.

Major edits

Major edits always appear in the history panel for the issue and are sent as e-mail notifications to users whose role for the issue have a notification setting of All or Important. Edits that are considered major include:

  • Initial creation of the issue.
  • Comments added to the issue.
  • Issue is moved to a new component.
  • Changes to the priority, severity or assignee of the issue.
  • A Closed, Verified, or Reopened status change to the issue.
  • Changes to custom fields that are marked as Major.

Minor edits

Minor edits only appear in the history panel for an issue if you have Full History toggled to On. Similarly, minor edits are only sent as e-mail notifications to users whose role for the issue have a notification setting of All.

Edits that are considered minor include:

  • Title changes
  • Hotlist changes
  • Related Issue changes (blocking, blocked by, duplicates)
  • Changes to status not explicitly stated as being major edits
  • Changes to the following fields: Reporter, Type, Verifier, CC, Found In, Targeted To, Verified In, In Prod
  • Changes to custom fields that are marked as Minor

Silent edits

Silent edits do not appear in the history panel for an issue, and they do not generate notification e-mails to any users. Edits that are considered silent include:

  • Changes to custom fields that are marked as Silent