Talk:Comparison of issue tracking systems

From Wikipedia, the free encyclopedia

You have new messages (last change).

3 more commercial ones are listed here, i will add them when i get a chance --phalseid 14:27, 26 September 2006 (UTC) (helpstar only works under IE!) http://helpstar.com/aboutus/ourcompetition.asp

When I started this article, I was thinking of just ticket-tracking or issue-tracking systems, specifically to the exclusion of the more specialized bug-tracking systems (e.g. Bugzilla), which may be better treated separately. Or maybe just include them all here until the article gets big enough to split apart. —Fleminra 20:41, 11 April 2006 (UTC)

Contents

[edit] Proposals

It would really be extremly helpful to have list Top 10 list of the software system. It is quite clear that it will not be possible to have a objective list but the list is to long to test all of the systems so a little help would be much appreciated at which systems to look first! —The preceding unsigned comment was added by 193.17.11.20 (talk • contribs) 07:38, November 16, 2006 (UTC)

[edit] Remedy

Added a row for Remedy (very commonly-used trouble-ticketing system). Now needs to be populated with data. --69.140.157.138 04:40, 21 June 2006 (UTC)

[edit] PHP Support Tickets

Please, add http://www.phpsupporttickets.com/ (I haven't any relation with them ;)) —The preceding unsigned comment was added by Cwolfsheep (talk • contribs) 12:17, July 9, 2006.


[edit] Accuracy of the Source code revision control system integration" column

We have looked at this table for a product evaluation. We find that the "Source code revision control system integration" column is very misleading. First "integration" can mean a lot of things and should be defined. It can be a very basic linking mechanism, or it can be a very integrated system with change set attached to bugs, approval (the code is only commited in the SCM trunk when the bug is closed, etc..). Then, practically, the information is far from accurate. For example, for Bugzilla, the integration with "CVS, Subversion, Perforce" only exist with third-party project such a scmbug, which is far from mature, and difficult to deploy. I think that this column should:

* mention how the integration can be done (third-party module, integrated plugin...)
* mention the level of integration it provides. Something very simple like three level (tight/loose/minimal for example) would probably be enough.

I even wonder if that column shouldn't be removed entirely. (Farialima 20:35, 23 February 2007 (UTC))


[edit] Issue tracking vs. bug tracking

Most of the systems that exist till date either cater to normal issue tracking or bug tracking. Thats is why it is okay to have two categories: one Issue tracking and other bug tracking. What about the system that cater to both ([tBits] for example)? —The preceding unsigned comment was added by Alpha0 (talk • contribs) 21:10, August 8, 2006.

I was thinking that the capabilities of an "issue-tracking" system are roughly a subset of the capabilities of a "bug-tracking" system; i.e. bug trackers are a specialization of issue trackers. If that's true, one could use any of the bug trackers for tracking "issues" (e.g. for a help desk), so all of the table rows for bug trackers could be duplicated in the issue-tracking group. Anyway, among all of these systems, I only know Bugzilla really well, so maybe that explains my viewpoint. I don't feel too strongly one way or the other. —Fleminra 19:03, 9 August 2006 (UTC)
Correct but to certain extent. To fit any bug tracking system into another issue tracking or ticketing system, the system should support extending the fields and modifying the workflow. Which I think only few bug tracking systems support. As far as I understand Bugzilla allows configuring field and roles but not the workflow. tBits which we have recently developed is one such system allows desiging new workflows too. The core of the system doesnt have any fields and workflow. It can be configured so that it can be used in any kind of workflow management solution.
My question still remains: Should we include such systems in both the categories or should we create a separate category called "Both"? —The preceding unsigned comment was added by Alpha0 (talk • contribs) 20:15, August 11, 2006.
As I think about it, it might be better to do away with the "bug tracker" or "issue tracker" classification altogether, and just add columns to indicate whether each product implements the features that make the product suitable for one purpose or another. E.g., it might be nice to have a column for "customizable workflow." (I believe you are correct about Bugzilla — the only way to add workflow stages is to change the source code; otherwise additional workflow steps pretty much have to be simulated using the "flags" mechanism.) —Fleminra 02:37, 13 August 2006 (UTC)
I agree with this. I don't think we need two seperate categories here, and having columns detailing a few main features (bug tracking, etc) would make it much easier to read/compare solutions. If bug tracking systems need a more detailed comparison, maybe that should be under a seperate article. —Beethoven05 17:06, 22 August 2006 (UTC)
As someone who has just stumbled across this article, looking for comparisons, I think that adding an extra section 'Combined Issue/Bug tracking' or the like would be useful. Just my two cents worth. Evolve2k 22-08-2006
The more I think about this, but better I think it would be to remove dedicated bug tracking products from this article and move them to their own comparison article. Bug tracking is a specific subset of issue tracking that has its own set of features to be compared. Items which do both should be left on the list. Is this kind of the consensus that has been reached? Beethoven05 21:04, 31 August 2006 (UTC)
Sounds good to me. The table has grown to become unwieldy. —Fleminra 18:38, 5 September 2006 (UTC)

[edit] tBits removal

Why tBits has been removed? tBits does contain the external links but there are still others having external links and I think this place provides a great info to an end user by providing the various avaible systems at single page and this comparision proves highly useful to an individual evaluating the various products. Let the wiki not present the incomplete information. —The preceding unsigned comment was added by 203.163.239.59 (talk • contribs) 18:01, August 21, 2006.

I suppose for the same reason that the tBits article was deleted (see deletion discussion). Personally, I would let entries on comparison articles such as this one stand on their absolute technical merits and not on their popularity, but I'm probably in the minority with that opinion. —Fleminra 02:44, 22 August 2006 (UTC)
I removed tBits because it was part of a pattern of edits that is consistent with self-promotion of a company. Wikipedia works best when edits are made by neutral third parties, not by editors with a self-interest in the organization. A small set of editors has been basically adding only tBits links to a variety of articles and as well as creating the deleted article. This behaviour is typical of someone attempting to promote a business or trying to improve the search engine rank of a non-notable corp and is inconsistent with the spirit of Wikipedia. The company and anonymous IPs that edit on its behalf all trace to India. Coincidence? I'm about to take an extended break from Wikipedia, so other editors here will need to determine if self-interest edits are acceptable in this article, or not. JonHarder 20:43, 22 August 2006 (UTC)

[edit] Additional columns

Pro's to more columns: the table is more useful. Con's: the more out-of-date the data could potentially become. With that in mind, potential columns that could be added: ( - Michael 06:56, 28 August 2006 (UTC) )

  • As mentioned above, the "issue tracking" and/or "bug tracking" shouldn't be a separate list, but rather an additional column as to whether or not the software could be used for issues, and/or bugs (perhaps just a single column, with multiple values allowed: { issues, defects, ...?} . It's rarely bugs XOR issues.
  • How about a column for the home page of the software package...!?!? How could that be overlooked? I guess "googling it" truly has become ubiquitous...
  • Software release version (especially valuable to compare if some software is at version 7.9 vs. version beta-19, etc.)
  • (add your column here)

[edit] More about additional columns

Here's another comparison chart, with some different ideas about what columns are important.

http://geekswithblogs.net/flanakin/articles/CompareWebTrackers.aspx

I added the column "Unicode Support" to this article.

Ctrager 01:15, 24 September 2006 (UTC)

[edit] Added FSF's GNATS

I added a skeleton of an entry for the FSF's GNATS bugtracker. Would someone who knows more about GNATS internals please flesh it out. Frotz 02:54, 23 March 2007 (UTC)

Retrieved from "http://en.wikipedia.org../../../c/o/m/Talk%7EComparison_of_issue_tracking_systems_f820.html"