お気に入りのチケットシステムは何ですか？[閉まっている]

私は発券システムの市場にいます、そして、私は誰もが何を使用しているかに興味があります。お気に入りのチケットシステムと、それがとても気に入っている理由を投稿してください。

発券システムを選択する際の基準は次のとおりです。

• オープンソースでなければなりません
• ユーザーは、やり取りの100％を電子メールで行える必要があります。Webインターフェースを使用する必要はまったくありません。顧客のWebインターフェイスがあるかどうかはあまり気にしません。
• メールで可能な限り処理できるようにする必要があります。（少なくとも、メールでチケットに返信させてください）
• 依存関係がほとんどない、インストールが非常に簡単なはずです。
• Webインターフェースでは、目を丸くしたくありません。

あまり気にしないこと：

• 時間追跡。
• 優先順位付けは大きな優先事項ではありません。（うめき）
• サブタスク、タスクの依存関係、キューなど
• メールから問題を追跡システムに持ち込むのに役立たない他のほとんどのこと。

過去にTracをチケットシステムとして正常に使用しました（wiki、リポジトリなどをオフにしました）。メールプラグインを知っていれば、Tracを使用したりRedmineを使用したりすることはありません。以前の会社では、ほぼすべての基準を満たすRequest Trackerを使用していましたが、依存関係が非常に多かったため、実行する必要のあるものが他になかったため、最終的に価値がないと判断しました。

私はOTRSを実行しており、すべての電子メール要件を満たし、セットアップは非常に簡単でしたが、（IT）Webインターフェースは本当に嫌いです。おそらく私はそれを間違って使用しているかもしれませんが、チケットのリストを処理し、何をすべきかを見つけるのを支援する方法は、RTよりもはるかに劣っています。

たぶん、私は非常にきびきびしているだけかもしれませんが、私は毎日選択するどんなシステムでも使用しなければならないだろうと思います。また、ユーザーがhelp@example.comと対話するだけでよい限り、ユーザーには透過的です。

それで、あなたが本当に好きなものを使用している/使用しているのはなぜですか？

トラッカーをずっとリクエストしてください。

絶対に最新のバージョンを使用することに関心がない限り、依存関係は以前ほど問題になりません。RHEL5システムでは、EPELを使用して「yum install rt3」を実行するようにシステムを設定するだけです。Ubuntuでは、「apt-get install request-tracker3.6」に似ていますが、「apt-cache search request-tracker rt3」は関連するすべてのパッケージのリストを提供します。

はい、これらのオプションは両方とも多くのperlモジュールを取り込みますが、そうですか？すでにそれらを構築し、それらを最新の状態に保つことを心配している誰かがいます。

Best Practicalの「RT：Request Tracker」を使用します。私はそれがオープンソースであることを99％確信していますが、あなたはすでにそれを使用しているので、あなたはそれが何ができるかを知っているべきです。

オープンソース：

Redmine ; 決定的。それは使いやすく、軽量のフットプリントを持ち、私のニーズを満たします。

所有権：

ジラ ; ヘビー級。チケットへの本当にプロセス管理のため。

私のお気に入りはJIRAです。オープンソースですが無料ではありません。グリッチなしで2年以上ここで動作します。その主な強みはカスタマイズ可能なワークフローです。そのため、追跡システムを独自のワークフロー（人々が慣れていても、それが悪いとはいえ）に合わせて調整することができます。

OTRSと言わざるを得ないでしょう。まず、オープンソースであり、多くの大規模組織で使用されています。私は現在働いている場所を含む2つの会社でそれを実装しました。私は毎日それをすべてに使用しました。チケット機能へのメールがあり、ADで簡単に認証できます。見てみるか試してみてください。過去にNumara Track-Itを使用したことがありますが、大丈夫でした。しかし、クライアントは遅くて太っていました。彼らのFootPrints Webソフトウェアは、Track-Itを使用した後のはるかに優れたソリューションになると思います。

ここでは非常に明白になろうとはしていませんが、Bugzillaは、Eメール経由でのバグの返信やEメール経由のバグ報告さえも許可するようにかなり簡単に構成できます。「whine」（未解決のバグに対してクエリを実行し、電子メールで出力を送信する）など、他の多くの優れた電子メール機能があり、利用可能なカスタマイズや統合がたくさんあります。最後に、それをインストールするのは本当に簡単で、ほとんどのperlモジュールがそこにあることを望んでおり、すぐに稼働させることができます。

私の会社では、これを非常にうまく使用し、開発者のIDE（Eclipse with Mylyn）、サブバージョンSCM（フックとWWW :: Bugzillaを使用）、さらにはビルドシステムと統合しました。QAの人たちは、卓越したチケット管理デスクトップアプリケーションであるDeskzillaを使用しています（これにはJiraバージョンもあります）。

ここでSpiceWorksを使い始め、とても気に入っています。唯一の欠点は、当たり障りのないユーザーポータルです。

私はFogBugzを使い始めたばかりで、これまでのところ気に入っています。

Request Trackerはかなり堅実です。私たちは主にレガシーの理由で使用します（ここ数年で持っていたものです）。本来の仕事をします。これ以上言うことはありません。

TrackITを使用します。何年もそれを使用して...今のところこれまでのところ。

うーん、私は実際にチケットシステムが好きな人は多くないと思います。

どのチケットシステムが最も嫌いなのかと尋ねると、私の答えはRemedy Action Request Systemになります。

Assemblaは高速で軽量でありながら、必要なものを提供します。

カヤコを使ったことがあります。オープンソース（php / mysql）で動作しますが、いくらかお金がかかります。価格に関してはそれほど悪くはありませんが、無料かオープンソース技術のどちらを求めているのかわかりません。すべてはメールで行われ、目には簡単で、手頃な価格で、インストールが簡単で、しっかりしたサポートがあります。

私はFlysprayで良い経験をしました。

シンプルで優れたホスティングソリューション：Zendesk

すばらしいレポートとプロセス管理/ワークフローを備えたヘビーチケット（エントリの最高の障壁）：JIRA

Windowsベースのシステム、システム管理と統合、エージェントの展開：Kaseya