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

重要

セキュリティイシューは [e-mail] に のみ 報告してください。これは長年にわたり信頼性の高いDjango開発者のみに公開されているプライベートなリストであり、そのアーカイブは公開されていません。詳細は our security policies を見てください。

そうでなければ、 ticket tracker にバグ報告や新機能提案をする前に、以下のことを検討してください：

• ticket tracker で、 searching または custom queries を動かすことで、ほかの人がバグや機能のリクエストをファイルしていないことを確認してください。
• ticketシステムをサポート問い合わせに使用しないでください。 django-users リスト、もしくはIRCチャンネルにて #django を使用してください。
• Don't reopen issues that have been marked "wontfix" without finding consensus to do so on the Django Forum or django-developers list.
• Don't use the ticket tracker for lengthy discussions, because they're likely to get lost. If a particular ticket is controversial, please move the discussion to the Django Forum or django-developers list.

バグレポート

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

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

以前に作成されたticketのライフサイクルを理解するため、ドキュメントの triaging-tikets を参照してください。

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

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

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

機能のリクエスト

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

• リクエストする機能は、本当にDjangoコアの改修が必要かどうか確認してください。例えば、データベースエンジンの追加要望のような、独立したアプリケーションやモジュールの開発で対応可能な場合は、独立した開発をお勧めします。その後、あなたのプロジェクトがコミュニティーから十分に支持されれば、Djangoに含めるか検討することになります。
• First request the feature on the Django Forum or django-developers list, not in the ticket tracker. It'll get read more closely if it's on the mailing list. This is even more important for large-scale feature requests. We like to discuss any big changes to Django's core before actually working on them.
• 不足している機能とどのように実装したいのかを明瞭かつ簡潔に記載してください。可能であればコード例も含めてください(機能しなくても問題ありません)。
• *なぜ*その機能が必要なのか説明してください。最小のユースケースを説明することで、他の人がその機能がどこに適合するのか、既に他の方法で同じ事が達成されていないかを理解する助けになります。

If there's a consensus agreement on the feature, then it's appropriate to create a ticket. Include a link to the discussion in the ticket description.

As with most open-source projects, code talks. If you are willing to write the code for the feature yourself or, even better, if you've already written it, it's much more likely to be accepted. Fork Django on GitHub, create a feature branch, and show us your work!

Documenting new features. も参照してください。

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

Whenever possible, we strive for a rough consensus. To that end, we'll often have informal votes on django-developers or the Django Forum about a feature. In these votes we follow the voting style invented by Apache and used on Python itself, where votes are given as +1, +0, -0, or -1. Roughly translated, these votes mean:

• +1: "I love the idea and I'm strongly committed to it."
• +0: "Sounds OK to me."
• -0: "I'm not thrilled, but I won't stand in the way."
• -1: "I strongly disagree and would be very unhappy to see the idea turn into reality."

Although these votes are informal, they'll be taken very seriously. After a suitable voting period, if an obvious consensus arises we'll follow the votes.

However, consensus is not always possible. If consensus cannot be reached, or if the discussion toward a consensus fizzles out without a concrete decision, the decision may be deferred to the steering council.

Internally, the steering council will use the same voting mechanism. A proposition will be considered carried if:

• There are at least three "+1" votes from members of the steering council.
• There is no "-1" vote from any member of the steering council.

Votes should be submitted within a week.

Since this process allows any steering council member to veto a proposal, a "-1" vote should be accompanied by an explanation of what it would take to convert that "-1" into at least a "+0".

Votes on technical matters should be announced and held in public on the django-developers mailing list or on the Django Forum.