Talk:Issue tracking system

Merge from Ticket (IT support)

I recently split the ticket article, which was large and unwieldy, into a disambiguation page and several (admittedly terrible) smaller articles. I don't have time to clean up all those smaller articles right now, but I thought this looked like a close enough match for Ticket (IT support), that a merge might preclude the need for cleanup. Acdixon 19:41, 9 March 2007 (UTC)

I don't envy customer support one bit, but I can show the world how they get their work done! DoomBringer 08:59, 12 Jun 2005 (UTC)

Agree, my vote is for them to stay separate.--A software programmer

Agreed, it doesn't make sense to keep it separate. Night Gyr (talk/Oy) 22:59, 10 May 2007 (UTC)

Issue tracking encompasses much more than help tickets. A help desk is a help desk. Issue tracking can also include SLA management, task tracking, project tracking, equipment tracking, creating a knowledge base, CRM, etc. I think they should be kept separate, and infact many functions could be broken out. Ldunbar 14:31, 30 May 2007 (UTC)

A ticket is more a customer service driven concept, while issue is more a change management driven concept. My vote is to keep them separated. Kslotte (talk) 11:33, 30 May 2009 (UTC)

Totally Agree with the original intent of Acdixon, and happy with the result of the merged article —-— .:Seth_Nimbosa:. (talk • contribs) 08:16, 19 September 2009 (UTC)

Please separate. I just landed on this page looking for support tracking, but this article hijacks that for bug tracking which is different. I agree with Kslotte above - customer service vs change management make for a very different emphasis in the final product. Nothing in this article helps me out in my research on IT Support Ticket management. PLEASE REVERSE THE MERGE. 20:45, 3 February 2010 —Preceding unsigned comment added by 75.106.214.134 (talk)

Issue tracking system vs Bug tracking system

Hello, I'm sorry but I don't see the main differences between Issue tracking system and Bug tracking system. Maybe this 2 articles should be merged too. Best regards --Scls19fr (talk) 13:33, 18 January 2008 (UTC)

The difference is that the former is used by customer service/tech reps to support the customer, whereas the latter is more of a developer's tool -- they don't generally have contact with the customer.

So yes, they are very similar types of tracking systems, but they are necessarily designed differently to fit the different needs of the people using them. (Developers don't have to record phone calls, etc)

SilentAshes (talk) 06:37, 31 January 2008 (UTC)

From my point of view: a bug tracking system has a clear and pre-defined set of subjects: the developments for which the bugs are traced. For a bug the object (the product and even version) is clear. An issue has a much broader scope, most of the times it is regarding more than one product. In the evolvement of the issue, the connected products can even change, where a bug is connected to a product and only the list of versions can be extendes: Once the bug is found in a product-version, it is there. Finally, clients for a bug-tracking system are most likely testers that (up to a level) know what they are doing, they have a system that works and they can be teached on inserting bugs, where clients for issue-tracking can have issues with the issue system themself, it must be as easy as possible to insert an issue (subject and body text of an email should be enough to start an issue)

—Preceding unsigned comment added by 130.78.143.1 (talk) 08:52, 11 December 2008 (UTC)

I agree to merge Bug tracking system into Issue tracking system. I think that these two types of systems have more common features than differences. --StanContributor (talk) 21:00, 14 December 2011 (UTC)

@Scls19fr: From a technological point of view, they employ the same approach, and some systems may even be able to serve both equally well, but they are actually different concepts serving different purposes, as pointed out by other users above. I politely DISAGREE.

—-— .:Seth_Nimbosa:. (talk • contribs) 08:07, 19 September 2009 (UTC)

I see bug tracking as a specific instance of issue tracking, or to put that the other way, issue tracking is a higher level of abstraction. I've almost always argued for the higher level of abstraction, because it seems to me that it matters little whether the issue is a software bug, a hardware artifact, an end user having different expectations from the sales guys and the infamous "wouldn't it be nice if?". Whatever, the issue should be recorded, the implications recorded and the conclusions recorded. Even the need for revision management in bug tracking does not detract from that. Revision management applies just as much to user manuals, CAD designs, sales brochures, novels, laws, and all manner of other things.

213.83.117.162 (talk) 09:12, 7 October 2010 (UTC) Gordon Scott.

The term Issue tracking has a wider scope. But it includes Bugs. If you are only using it in a development team you can do with a "Bug-Tracking" system, but for wider use you would call it an "Issue-Tracking" system. So depending on the types of users and the scope of using it you can call it a "Bug-Tracking" system or an "Issue-Tracking" system. Basically someone enters an Issue because that person thinks something might be wrong or needs revision. After the person reports the Issue someone else (Designer, Product-owner,....) decides on the type of Issue. It can be a Bug. But it can be a request for change (RFC), it can be a misunderstanding and be rejected or it can be something else. — Preceding unsigned comment added by 194.171.184.14 (talk) 12:19, 17 October 2012 (UTC)

Completely agree with Gordon Scott; that Bug Tracking is a limited, special class of Issue Tracking. The term "Bug" in the context of "Bug Tracking" comes about from errors in software that require fixing (not withstanding the original cause of the expression; of an insect that literally flew into the back of a mainframe and caused an error). That has been extended by many to include "bugs" with the processes by which work is performed within an organisation, but that implies that everything reported is a Fault. The correct terminology is that a Bug is for tracking software errors and all other aspects are Issues. The Issue type in its simplest form can be "Bug", "Request", "Suggestion". The term "bug" simply cannot be used to describe a request to improve say delivery services of goods where no actual problem is perceived but an individual can see customer service improving by applying some changes to existing processes. Issue Tracking looks at the widest picture possible, whereas Bug Tracking looks at software only issues and Fault Reporting looks at only faults but system-wide and of any nature. A connotation of the word "Issue" is that there is a fault but in essence an Issue can be anything (from a Suggestion to a Fault). I completely disagree that Bug Tracking should be merged with Issue Tracking. [davcomnz - 14th Dec 2012] — Preceding unsigned comment added by Davcomnz (talk • contribs) 20:40, 13 December 2012 (UTC)

Issue management is entirely different

Issue management is a field of discipline, process / technique, whereas the article is about technological solutions for that purpose.
No need for a merge.

—-— .:Seth_Nimbosa:. (talk • contribs) 08:00, 19 September 2009 (UTC)

Don't merge w/Issue Management

• • I also support keeping two different articles. Issue tracking is different than bug(defect) tracking. Issue could be anything that you raise a flag but you are not sure if this is really a defect. — Preceding unsigned comment added by TestTR (talk • contribs) 12:53, 15 July 2013 (UTC)

I agree with Seth (below); these are separate topics. In fact, I was looking specifically for a brief overview on issue tracking systems, and found this article on my first search attempt. To me, that suggests the article is well-conceived. 96.232.24.63 (talk) 16:43, 2 November 2009 (UTC)Steve

I also agree, I think there's enough consensus here to remove the template. -- Scarpy (talk) 23:00, 7 March 2010 (UTC)

I support keeping two different articles. Anyone who has designed bug tracking software and issue tracking software is aware of enough differences in scope and characerization that necessitate the development of different software for each use. The similarities may enable the reuse of code, but one system cannot ideally serve both issues. As this discussion has been going on for ages, isn't it time to reach a consensus and end it ? --Gil.shabtai (talk) 09:46, 20 March 2012 (UTC)

Combine because they are short

My experience has been that tracking software comes in many flavors depending on the organization that uses it. I've seen SW development in R&D and IT departments where the term "trouble ticket" has two different meanings. Given the relatively short size of both articles I would vote to combine with appropriate sections for each flavor. Bug tracking, issue tracing, Change control, etc are all methods/systems used to manage software whether it is developed, or deployed. DCwom (talk) 13:01, 20 August 2013 (UTC)

Architecture section isn't relevant, correct or cited

I don't understand why this article tries to explain how an issue tracking system works under the hood. I also think it's wrong to try and guess how "most" issue tracking systems are designed. Is a database really the main storage repository for all data? Is there really a business logic layer of the application? Has someone done a survey of issue tracking software and it's design? I'm going to remove this section. Ben — Preceding unsigned comment added by B3nCrin (talk • contribs) 13:47, 3 April 2014 (UTC)

Seeking sources for ticket definition

A definition here is provided for a ticketing system based on individual tickets: "amenable to a decisive resolution", "each issue is unique", "precisely one person assigned formal responsibility to move the issue forward" and on the system, "generally quality or feature related", "service-related" or "relationship-based". This is a broad definition, good that means this article will be valuable for many people. But I hope primary sources can be shown for this definition. Full Decent (talk) 18:38, 28 August 2019 (UTC)