バグの報告と機能のリクエスト—Djangoのドキュメント
バグの報告と機能のリクエスト
重要
セキュリティの問題のみを [email protected] に報告してください。 これは、長年にわたって信頼性の高いDjango開発者のみが利用できるプライベートリストであり、そのアーカイブは公開されていません。 詳細については、セキュリティポリシーをご覧ください。
それ以外の場合は、バグを報告したり、チケットトラッカーの新機能をリクエストしたりする前に、次の点を考慮してください。
- チケットトラッカーで検索またはカスタムクエリを実行して、誰かがバグまたは機能のリクエストをまだ提出していないことを確認してください。
- チケットシステムを使用してサポートの質問をしないでください。 そのためには、 django-users リストまたは #django IRCチャネルを使用してください。
- django-developers でコンセンサスを見つけることなく、「wontfix」とマークされた問題を再開しないでください。
- チケットトラッカーは迷子になる可能性があるため、長時間のディスカッションには使用しないでください。 特定のチケットについて物議を醸す場合は、ディスカッションを django-developers に移動してください。
バグの報告
よく書かれたバグレポートは信じられないほど役に立ちます。 ただし、バグ追跡システムの操作にはある程度のオーバーヘッドが伴うため、チケットトラッカーを可能な限り有用な状態に保つためにご協力いただければ幸いです。 特に：
- 実行 FAQ を読んで、問題がよく知られた質問であるかどうかを確認してください。
- Do は、表示されているものがバグかどうかわからない場合は、 django-users または #django first で質問してください。
- Do は、完全で再現性のある特定のバグレポートを作成します。 問題の明確で簡潔な説明と、問題を再現するための一連の手順を含める必要があります。 コードスニペット、テストケース、例外バックトレース、スクリーンショットなど、できるだけ多くのデバッグ情報を追加します。 小さなテストケースは、バグをすばやく確認するのに役立つ方法であるため、バグを報告するための最良の方法です。
- django-developers に投稿しないでくださいは、バグレポートを提出したことを発表するためだけです。 すべてのチケットは別のリスト django-updates に郵送されます。このリストは、開発者と関心のあるコミュニティメンバーによって追跡されます。 提出されたとおりに表示されます。
チケットを作成した後のチケットのライフサイクルを理解するには、トリアージチケットを参照してください。
ユーザーインターフェイスのバグと機能の報告
バグや機能のリクエストが視覚的な性質のものに触れている場合は、従うべき追加のガイドラインがいくつかあります。
- 最小限のテストケースと視覚的に同等のスクリーンショットをチケットに含めます。 ブラウザに加えたクレイジーなカスタマイズではなく、問題を自慢して見せてください。
- 静止画像を使用して問題を明らかにするのが難しい場合は、 brief スクリーンキャストをキャプチャすることを検討してください。 ソフトウェアで許可されている場合は、画面の関連領域のみをキャプチャします。
- DjangoのUIの外観や動作を変更するパッチを提供している場合は、スクリーンショット/スクリーンキャストのの前との後に添付する必要があります。 これらが不足しているチケットは、トリアージャーが迅速に評価することは困難です。
- スクリーンショットは、他の優れたレポート作成方法を免除するものではありません。 スクリーンショットに表示されている動作を再現する方法について、URL、コードスニペット、およびステップバイステップの説明を必ず含めてください。
- 関係者がチケットを見つけられるように、チケットにUI / UXフラグを設定してください。
機能のリクエスト
私たちは常にDjangoの改善に努めており、機能のリクエストはその重要な部分です。 リクエストを最も効果的に行うためのヒントを次に示します。
- 機能が実際にDjangoのコアの変更を必要としていることを確認してください。 アイデアを独立したアプリケーションまたはモジュールとして開発できる場合（たとえば、別のデータベースエンジンをサポートしたい場合）、おそらく独立して開発することをお勧めします。 その後、プロジェクトが十分なコミュニティサポートを集めた場合、Djangoに含めることを検討する場合があります。
- まず、チケットトラッカーではなく、 django-developers リストで機能をリクエストします。 メーリングリストに載っていれば、もっと詳しく読まれます。 これは、大規模な機能要求にとってさらに重要です。 実際に作業する前に、メーリングリストでDjangoのコアに大きな変更があれば話し合いたいと思います。
- 不足している機能とは何か、およびそれをどのように実装してほしいかを明確かつ簡潔に説明してください。 可能であれば、サンプルコードを含めます（機能しなくても問題ありません）。
- この機能が必要な理由理由を説明してください。 最小限のユースケースを説明することは、他の人がそれがどこに適合するか、そして同じことを達成する他の方法がすでにあるかどうかを理解するのに役立ちます。
機能についてコンセンサス合意がある場合は、チケットを作成するのが適切です。 チケットの説明に django-developers に関するディスカッションへのリンクを含めます。
ほとんどのオープンソースプロジェクトと同様に、コードは話し合います。 この機能のコードを自分で記述したい場合、またはさらに良いことに、すでに記述している場合は、受け入れられる可能性がはるかに高くなります。 GitHubでDjangoをフォークし、機能ブランチを作成して、あなたの作品を見せてください！
参照：新機能の文書化。
意思決定の方法
可能な限り、大まかなコンセンサスを目指して努力します。 そのために、機能について django-developers に非公式に投票することがよくあります。 これらの投票では、Apacheによって発明され、Python自体で使用される投票スタイルに従います。投票は、+ 1、+ 0、-0、または-1として与えられます。 大まかに翻訳すると、これらの投票は次のことを意味します。
- +1：「私はそのアイデアが大好きで、それに強くコミットしています。」
- +0：「私には大丈夫だと思います。」
- -0：「わくわくしていませんが、邪魔になりません。」
- -1：「私は強く反対し、アイデアが実現するのを見るのは非常に不幸です。」
django-developers に対するこれらの投票は非公式ですが、非常に真剣に受け止められます。 適切な投票期間の後、明らかなコンセンサスが得られた場合は、投票に従います。
ただし、コンセンサスが常に可能であるとは限りません。 コンセンサスに達することができない場合、またはコンセンサスに向けた議論が具体的な決定なしに失敗した場合、決定は技術委員会に延期される可能性があります。
内部的には、テクニカルボードは同じ投票メカニズムを使用します。 次の場合、提案は実行されたと見なされます。
- 技術委員会のメンバーから少なくとも3つの「+1」投票があります。
- 技術委員会のメンバーからの「-1」の投票はありません。
投票は1週間以内に提出する必要があります。
このプロセスでは、技術委員会のメンバーが提案を拒否できるため、「-1」の投票には、その「-1」を少なくとも「+0」に変換するために必要なことの説明を添付する必要があります。
技術的な問題への投票は、 django-developers メーリングリストで発表および公開する必要があります。
