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 lets 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 would allow for more streamlined 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. |
| Project | A goal-driven effort with a finite start and end, focused on creating a unique product, service, or result. |
| Milestone | A collection of work that represents an important achievement on the path to completing a project. Milestones may also be used to represent launches or releases. |
| Feature | A collection of work that provides a specific value to the user. |
| Epic | A large collection of work towards a common objective. |
| Story | A small collection of work that provides a specific value to the user. |
| Task | A small unit of work. |
| Program | A collection of thematically related goals (projects, features, milestones, epics). |
Issue priority
The Priority field lets 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 lets 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 assigned to it. |
| Assigned | The issue has a person assigned to it. That person appears in the Assignee field. |
| In Progress (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 by the user in the Verifier field. |
| 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 In Progress. 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 appears 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 Assign to me. 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 In Progress.
If you are the assignee of an issue and its status is In Progress, 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 New if the issue has no assignee, or Assigned if the issue has an assignee.
Issue hovercards
An issue hovercard contains information such as the title, ID, description and current status of an issue. Additionally, it contains a CC Me button that adds you to the issue's CC list (if you are already on the CC list, the button reads (Un-CC Me). For example:
Issue hovercards appear when you hover over the following:
- Issue ID found in the Blocked By, Blocking, or Duplicates tab of the Related Issues tray.
- Issue ID in the Blocked By, Blocking, or Duplicate Of column of an issue search results page.
- Link to an issue found in the Recent Issues panel, located on the right of a Create Issue page.
- Status field on a issue page that is marked as duplicate.
- Link to the canonical issue found in the yellow bar at the top of a page that is marked as duplicate.
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 email notification when the change occurs.
Closing edits
Closing edits change the status of an issue from Open to Closed. Closing edits appear in the history panel for the issue. Closing edits are sent as email notifications to users with one of the following notification settings: All Updates, Major Updates, or Closure Only.
For a complete list of statuses that close an open issue, see issue status.
Major edits
Major edits always appear in the history panel for the issue. After a major edit, an email notification is sent to users that have a notification setting of All Updates or Major Updates. 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, retention or assignee.
- A Closed, Verified, or Reopened status change.
- 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 the filter level set to Full history. Similarly, minor edits are only sent as email notifications to users whose role for the issue have a notification setting of All Updates.
Edits that are considered minor include:
- Title changes
- Hotlist changes
- Adding Attachments
- 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, Found In, Targeted To, Verified In, In Prod
- Changes to custom fields that are marked as Minor
Silent edits
Silent edits don't generate notification emails to any users. Edits that are considered silent include:
- Adding or removing entries from the CC or Collaborator fields (unless the user or group is newly being added or removed)
- Editing a comment
- Changing a custom field that is marked as Silent
Issue Access Limits
Issue Tracker supports access control restrictions that allow for issues to have a smaller set of accessors than other issues in the same component.
Issue Admins are allowed to update the restriction status of an issue to one of four issue access levels:
Default access - The normal rules apply: an issue with the Default access level has the same accessors as all other issues in the component.
Limited commenting - Only identities who are explicitly listed on the issue as assignee, collaborator, verifier, or CC will be allowed to comment on the issue, regardless of whether they have comment permissions for other issues in the component. Identities with Admin Issues permission on the component also retain comment access. View access remains default.
Limited visibility - Only explicitly listed identities (assignee, collaborator, verifier, or CC) retain view access to the issue.
Limited visibility + Google - Only explicitly listed identities (assignee, collaborator, verifier, or CC), Full-Time Googlers, and internal automation accounts retain view access to the issue.