問題タブ [issue-tracking]

分散したチームによる中規模のWebアプリケーションオープンプロジェクトの課題追跡システムを探しています。これを独自のサーバーで実行することを計画しています。新しいユーザーが新しい問題を提出するのは非常に簡単である必要があり、他のソフトウェアとうまく統合する必要があります。

重要度の高い順に、私たちの主な要件：

• オープンソース
• 非常に新しいユーザーフレンドリーなバグ送信が可能
  • 新しい号の提出は、（登録後）入力する画面が1つだけで、表示されるフィールドが少ない（たとえば、「概要」と「説明」だけが適切）、できるだけ簡単である必要があります。
  • Google Codeは、私たちが好む種類のインターフェースの一例です。BugzillaのBugzillaインスタンス（https://bugzilla.mozilla.org/enter_bug.cgi）は、私たちが望まない種類の新しいバグ送信インターフェースの例です。
  • テンプレート/スキンを使用して簡単に変更できる限り、デフォルトの送信インターフェイスが新しいユーザーフレンドリーでない場合は問題ありません。新規ユーザーのバグ送信用の単純なビューに加えて、追加のフィールド（問題の割り当て先など）を備えたバグ編集用の「詳細ビュー」があると便利です。
• APIがあります。または、dbバックエンドに同時にアクセスする他のアプリケーションをサポートします（別のサーバーで実行されている他の別個のソフトウェアから問題を照会および変更したい）

重要度の高い順に、その他の望ましい基準：

• 日常の使用でイライラしない
• 比較的大きなコミュニティがあります
• hg（mercurial）とうまく統合します
• 外部との統合に適しています：
  • サポートデスク/リクエスト追跡ソフトウェア
  • プロジェクト管理ソフトウェア
  • 認証システム（および/またはOpenIDログインをサポート）
• 基本単位; 課題追跡システムを変更する場合は、他のユーザーが簡単にインストールできるモジュールとして、これらの改善点をリリースしたいと考えています。
• ある種のシンプルで使いやすい問題重要度投票システム、たとえばGoogleコードのスターを使用するのに適しています。このようなコンポーネントを作成または変更して、独自の外部投票システムにプラグインする予定です。
• SugarCRMとの統合に適しています

「受け入れやすい」とは、必要に応じて課題追跡システムの拡張機能を自分でコーディングすることを意味しますが、課題追跡システムのアーキテクチャはそのような拡張機能に対応できる必要があります。

サポートデスクまたはプロジェクト管理機能も含む課題追跡システムは、付属のものを使用する代わりに外部ソフトウェアを統合することを選択できる場合にプラスになります。別のウィキは必要ありません（すでに気に入っているウィキがあります）。

Googleの検索（コメントを参照）によると、最も人気のあるオープンソースの課題追跡システムは、trac、bugzilla、mantis、RT（および場合によってはLaunchpad）です。また、これらの問題追跡システムと、誰かがRedmineについて悪いことを言っているRedmineとの最近の比較を見たことがないので、Redmineも含めました。世論調査では、Redmineが他の人を打ち負かすことがあります。他の人を自由に提案してください（基準の1つは「比較的大きなコミュニティ」であることを念頭に置いてください）。

間違いなく、そこには複数の優れた課題追跡システムがあります。上記のリストの多くは、他のソフトウェアと拡張可能で統合可能であると主張しています。最も役立つのは、複数を使用したことのある人による課題追跡システム間の直接比較です。

これらは、拡張性、統合性、およびスキナビリティに関して互いにどのように比較されますか？

これらを複数使用したことがある場合、どれをお勧めしますか。また、他にどの使用をしましたか。

これらのうち、すでに多数の認証システム/サポートデスクシステムなどと統合されているのはどれですか？

特定の人気のあるオープンソースの課題追跡システム（特に上記のいずれか）が私たちの状況に適していない理由を説明するコメントは大歓迎です。これは私に時間を節約します。

ありがとう！

Jiraでは、QAテスターが開発者が未リリースの機能を実装する方法に問題を見つけた場合、それを新しいバグとしてログに記録する必要がありますか？それとも、問題をコメントとして記録し、問題を再度開く方がよいでしょうか。

彼らが既存の問題についてのコメントとしてそれを入力した場合、タイムトラッキング機能を使用すると、その問題の実装に実際にかかった時間をより正確に把握できると思います。一方、新しいバグを作成する場合は、品質向上の目的で取り組んでいる問題の数に対して、開発者が生成しているバグの数を追跡できます。

それぞれのアプローチの長所と短所は何ですか？上で概説した両方の利点を達成する方法はありますか？

何かが足りないように感じますが、Gitの問題READMEにはそれ自体のインストール方法が記載されていません。gitの問題をインストールするにはどうすればよいですか？

git-issuesのクローンを作成したので、最新のコピーを使用しています。

編集：

だから私は以下の答えに従ってgitを「インストール」しましたが、これが何が起こるかです：

そのため、README.textileの名前をREADMEに変更してから、/usr/local/bin

申し訳ありませんが、何か問題が発生しているように感じます。READMEファイルを/usr/local/bin入れる必要はありません。ここで何かが足りませんか？

編集2：

READMEファイルを移動した後でも、をgit help issues返しますNo manual entry for git-issues。どうすればそれを機能させることができますか？（今、私は大きな不満のように感じ始めています:)）

編集3：

「プッシュ」機能も機能しないのはなぜですか？私が行ったのは、ファイルを/ usr / local / binにcpし、次に同じファイルを/ usr / lib/git-coreにcpして何が起こるかを確認することだけです。

Python 開発のための課題トラッカーの選択に関する議論の要約はどこかにありますか? そうでない場合、そのような議論へのリンクはありますか?

私は、純粋に内部使用のためのシステムを開発する会社で働いています。開発者は数人しかいませんが、問題の追跡と機能のリクエストには redmine を使用しています。ただし、Issue Tracker にアクセスできるのはチーム リーダーだけであり、それ以外の人はチーム リーダーを通じて提案を行うことになっています。

これにより、開発者の作業負荷が軽減され、管理者は開発中の機能をより詳細に制御できるようになるという考えです。現実には、小さなバグや機能のリクエストを経験している人々から直接メールが送られてきます。

これは、ユーザーからのフィードバックを管理する適切な方法ですか、それとも既知の悪い習慣ですか? 内部の問題追跡の管理について説明している記事を見たことがないので、お尋ねしたいと思います。

多くのオープンソース開発者のように、私はおそらく数十の異なるプロジェクトの課題追跡システムと対話していることに気づきます。仕事用のものもあれば、趣味用のものもあります。頻繁に、まれに。バグを報告したり、パッチを提供したり、自分に影響を与える他の人のバグレポートをフォローしたり、自分のプロジェクトで自分の作業を整理したりすることもあります。

問題は、このアクティビティがWeb全体のさまざまなプロジェクトのさまざまなWebアプリ（github、bitbucket、trac、bugzilla、mantis、jira、...）に散在しており、私が試している問題のステータスを確認する場所が1つもないことです。上にとどまる。

自分に割り当てられたすべてのもの、報告したバグ、または更新を監視しているバグをすべて閲覧、検索、並べ替えることができる1つのダッシュボードのようなアプリが必要です。プロジェクト-これらすべての問題を手動でダッシュボードに再入力する必要はありません。他のトラッカーの既存の問題へのURLをフィードするだけで、その問題のステータスが追跡されます。

RSSフィードリーダーだけでほとんどそこにたどり着くことができますが、本当に便利な場合を除いて、アプリは関連するメタデータについて詳しく知る必要があるため、必要に応じて並べ替えやフィルタリングを行うことができます。

誰かがそのようなものを作ったことがありますか？少なくともコメントの追加、解決済みのマーキングなどの一般的なタスクに対して、書き込み機能も提供する場合はボーナス。

そんなことは聞いたことがないので、ずっと願っています。それが存在しない場合、私はそれをクラックする必要があるかもしれません。

現在 flyspray をバグトラッカーとして使用していますが、多くのタスク機能がなく、特にタスクのカレンダー ビューがありません (タスクを完了する必要がある日付を持つ締め切りタスクのみ)。

Google カレンダーのようなカレンダー付きの PHP バグトラッカーはありますか?

非常に単純な問題追跡ウィジェットを提案できますか。UserVoiceは、私たちのフォーラムに少し関わっていますが、そうではありません。私たちが望んでいるのは、人々が私たちに問題やメモを送ってURLを取得できるようにすることです。

私は、なぜ次のことが起こっているのか、絶対に唖然とします。

これが私のコードです：

結果は次のとおりです。

xが変更された理由がわかりません。

私の推測：どういうわけか、xは関数add_oneのグローバル変数として与えられています。'new_array = array'を含めたので、配列が何らかの形でグローバル変数xである場合、xは変更されません。ただし、「new_array = array」が実行されると、どういうわけかnew_arrayもグローバル変数xになりました。私は問題を起こさなかった関数add_oneの代替バージョンを書きました：

ローカル変数（つまり配列）が関数内のインデックスによって編集された場合、その関数の入力として取得されたグローバル変数に対してグローバルになりますか？

何が起こっているのかわかりません。説明をいただければ幸いです。

リリース、開発、機能、およびバグ修正ブランチで動作する git ワークフロー モデルに関する次の優れたブログ投稿に出くわしました: http://nvie.com/posts/a-successful-git-branching-model/

これは素晴らしいワークフローのように思えます。実際に本番環境で試してみたいと思っていますが、ある段落が私の注意を引き、不思議に思っています。

次のリリースにバージョン番号が割り当てられるのは、リリース ブランチの開始時であり、それ以前ではありません。それまでは開発ブランチに「次のリリース」の変更が反映されていましたが、その「次のリリース」が最終的に 0.3 になるか 1.0 になるかは、リリース ブランチが開始されるまで不明です。その決定は、リリース ブランチの開始時に行われ、バージョン番号バンピングに関するプロジェクトのルールによって実行されます。

この作業方法は、チケット発行およびバグ追跡システムにどのように反映されるのでしょうか? JIRA と BugZilla では、チケットが所属できる「バージョン」を作成します。リリース ブランチに切り替える前に、開発ブランチにある場合、チケットはどのバージョンに属しますか? すべてのブランチのイシュートラッカーにバージョンがありますか?

また、今後のリリースではなく、その後のリリースで実装することがわかっている機能チケットについてはどうでしょうか? この種のチケットの「今後」と「将来」のバージョンを作成する必要がありますか?

この分岐ワークフローがチケット/問題管理にどのように反映されるかについての洞察をいただければ幸いです。