バグレポートと機能のリクエスト¶

バグレポート¶

よく書かれたバグレポートは信じられないくらい有益です。しなしながら、バグチケットシステムの作業には手間がかかるため、チケットトラッカーを可能な限り便利に保つようにご協力をお願いします。特に、

• あなたの疑問が一般的なものである可能性がある際は、 FAQ を読んでください。
• バグかどうか確証が持てない場合には、まず|django-users| か #django で質問してください。
• 完全で再現可能な明確なバグレポートを作成してください。問題を明確かつ簡潔に記載し、再現方法を指示してください。コードの抜粋、テストケース、バックトレースのエクセプションやスクリーンショットなど、可能な限りの情報も追加してください。無駄のない小さなテストケースが最高のバグレポートであり、バグを確認する最善の方法です。
• バグレポートを提出したことだけで|django-developers| に投稿しないでください。全てのチケットは開発者や興味があるコミュニティーメンバ向けの|django-updates|で配信されるため、バグレポートの提出についてもそちらで確認します。

以前に作成されたticketのライフサイクルを理解するため、ドキュメントの チケットをトリアージする を参照してください。

ユーザーインターフェイスのバグや機能について報告する¶

あなたが報告するバグや機能が何らかの視覚的に確認できるものである場合は、以下の追加のガイドラインに従ってください。

• 最小のテストケースが視覚的に理解できるスクリーンショットをチケットに含めてください。あなたの素晴らしいブラウザのカスタマイズではなく、問題を示してください。
• 問題をスクリーンショットで示すのが難しい場合は、 簡潔な スクリーンキャストを撮影することを検討してください。可能なソフトウェアなら、問題に関連する領域のみを撮影するようにしてください。
• Django UIの挙動や見た目を変更するパッチを提案する場合は、 必ず 変更前と後のスクリーンショット/スクリーンキャストを添付してください。これらが含まれないチケットは、優先度を付けることが困難です。
• スクリーンショットは他のよいレポート方法を免除するものではありません。URL、コードの抜粋、スクリーンショットの挙動を再現するための詳細な手順が含まれていることを確認してください。
• チケットに UI/UX フラグを設定するのを忘れないでください。このフラグがあると、関係する人たちがチケットをすぐに発見することができます。

機能のリクエスト¶

我々は常にDjangoをより良くしようと努めており、ユーザーからの機能のリクエストは重要なパーツになります。リクエストを最も効果的に行うためのヒントをいくつか示します。

• リクエストする機能は、本当にDjangoコアの改修が必要かどうか確認してください。例えば、データベースエンジンの追加要望のような、独立したアプリケーションやモジュールの開発で対応可能な場合は、独立した開発をお勧めします。その後、あなたのプロジェクトがコミュニティーから十分に支持されれば、Djangoに含めるか検討することになります。
• まずは Django Forum や django-developers メーリングリストで機能をリクエストしてください。メーリングリストであれば、より詳しく読まれるでしょう。これは大規模な機能要望の場合はさらに重要です。私たちは、Django のコアに対する大きな変更は、実際に作業する前に議論したいのです。
• 不足している機能とどのように実装したいのかを明瞭かつ簡潔に記載してください。可能であればコード例も含めてください(機能しなくても問題ありません)。
• なぜ その機能が必要なのか説明してください。最小のユースケースを説明することで、他の人がその機能がどこに適合するのか、既に他の方法で同じ事が達成されていないかを理解する助けになります。

その機能に関するコンセンサスの合意があれば、チケットを作成するのが適切です。チケットの説明にディスカッションへのリンクを含めてください。

ほとんどのオープンソースプロジェクトと同様に、コードは語ります。もしあなたがその機能のコードを自分で書く気があるなら、あるいはもっといいのは、すでに書いてあるなら、それが受け入れられる可能性はずっと高くなります。GitHub で Django をフォークして、機能ブランチを作成し、あなたの作品を私たちに見せてください！

新機能のドキュメントを書く. も参照してください。

どのように決定が下されるか¶

可能な限り、私たちは大まかな合意を目指しています。そのため、機能についての非公式の投票を django-developers や Django Forum で行うことがよくあります。これらの投票では、Apacheが発明しPython自体で使用されている投票スタイルに従い、投票は +1, +0, -0, または -1 として行われます。大まかに訳すと、これらの投票は以下のような意味を持ちます:

• +1: "私はこのアイデアが大好きで、強くコミットしています。"
• +0: " 私は OKだと思います。"
• -0: "ワクワクはしないけど、邪魔にはならないと思います。"
• -1: "私は強く反対しますし、このアイデアが現実になるのを見るのは非常に不愉快です。"

これらの投票は非公式なものですが、非常に真摯に受け止められます。適切な投票期間の後、明らかなコンセンサスが得られれば、投票に従います。

しかし、常にコンセンサスが得られるとは限りません。コンセンサスが得られない場合、あるいはコンセンサスに向けた議論が具体的な決定がなされないまま頓挫した場合、その決定は 運営委員会 (steering council) に委ねられることがあります。

内部的には、運営委員会も同じ投票メカニズムを使用します。以下を満たす場合、議案は可決されたとみなされます:

• 運営委員会のメンバーから少なくとも3票の "+1" 投票があること。
• 運営委員会のどのメンバーからも "-1" の票が入らないこと。

投票は1週間以内に提出してください。

このプロセスでは、どの運営委員も提案に拒否権を行使できるため、 "-1" 票には、その "-1" を最低でも "+0" に変えるには何が必要かという説明を添えるべきです。

技術的なことに関する投票は、 django-developers メーリングリストか Django Forum で公開で発表され、行われるべきです。