Browse Prior Art Database

Method for Automatically Identifying Related Tickets in Issue Tracking Systems

IP.com Disclosure Number: IPCOM000246649D
Publication Date: 2016-Jun-24
Document File: 3 page(s) / 28K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method and system for automatically identifying related tickets in issue tracking systems. The approach uses technologies such as artificial intelligence to determine if two tickets in an issue tracking system either both describe the same issue or both describe issues that are related.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 50% of the total text.

Page 01 of 3

Method for Automatically Identifying Related Tickets in Issue Tracking Systems

Issue tracking systems often generate and hold multiple tickets for the same issue. For example, an authentication issue caused by the same bug might be open for multiple versions of the product, for example V1, V2, V3. An issue that is resolved for V1 is often difficult to find, meaning that teams spend time "re-solving" or "re-fixing" a single bug in the code for each release of the product. There is no automated way to identify that the issue described in ticket "X" is similar to (or the same as) the issue described in ticket "Y" and that the issue in ticket "Y" has already been solved. There is also no easy or automated way of determining how many unique issues exist in an issue tracking system.

The novel contribution is a method and system for automatically identifying related tickets in issue tracking systems. The novel system uses technologies such as artificial intelligence to determine if a newly opened issue ticket matches anything existing in the issue tracking system. It bases the similarity determination on factors such as any provided stack traces, logs, heap dumps, thread dumps and customer description. If the system identifies that the problem is similar to an existing problem, then it notifies the user of the duplication.

The algorithm explained herein is merely an overview of one possible implementation and is meant to serve as proof of feasibility. Extending the algorithm described below to identify identical issues for all of the products in an issue tracking system is a trivial task.

One possible implementation is as follows:

Create a database table (henceforth known as similar_tickets) to store related ticket pairs. The table contains the following columns:


 Unique id for ticket 1


 Unique id for ticket 2


 Timestamp for the execution of the ticket query that generated the data used to determine that these two tickets are related

Periodically (ideally when the system usage is lowest) poll the system for all tickets filed for the given product.

For each ticket {
split and categorize the different types of data attached to the ticket based on

existing methods. }

For each ticket x {

For each ticket y (excluding ticket x) {

         If there is an existing entry in the similar_tickets table that contains both ticket x and ticket y {

1


Page 02 of 3

             If neither ticket x nor ticket y has been updated since the timestamp described in the database table setup {
skip this ticket combination and move on to comparing ticket

}

For example, stack traces can be scored using the following process: Extract the most relevant features using term frequency inverse document frequency (TFIDF), treating each method on the stack like a single word in an n-gram. Treating each method as a single word in an n-gram allows the similarity score to account for the order in which the methods in the stack trace were called. To take this a step further, use fuzzy match...