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

重要

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

バグレポート

Before reporting a bug on the ticket tracker consider these points:

• Check that someone hasn't already filed the bug report by searching or running custom queries in the ticket tracker.

• Don't use the ticket system to ask support questions. Use the Django Forum or the Django Discord server for that.

• Don't reopen issues that have been marked "wontfix" without finding consensus to do so on the Django Forum.

• 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.

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

• あなたの疑問が一般的なものである可能性がある際は、 FAQ を読んでください。

• Do ask on Django Forum or the Django Discord server first if you're not sure if what you're seeing is a bug.

• 完全で再現可能な明確なバグレポートを作成してください。問題を明確かつ簡潔に記載し、再現方法を指示してください。コードの抜粋、テストケース、バックトレースのエクセプションやスクリーンショットなど、可能な限りの情報も追加してください。無駄のない小さなテストケースが最高のバグレポートであり、バグを確認する最善の方法です。

• Don't post to Django Forum only to announce that you have filed a bug report. All the tickets are mailed to another list, django-updates, which is tracked by developers and interested community members; we see them as they are filed.

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

Reporting user interface bugs

If your bug impacts anything visual in nature, there are a few additional guidelines to follow:

• 最小のテストケースが視覚的に理解できるスクリーンショットをチケットに含めてください。あなたの素晴らしいブラウザのカスタマイズではなく、問題を示してください。

• 問題をスクリーンショットで示すのが難しい場合は、 簡潔な スクリーンキャストを撮影することを検討してください。可能なソフトウェアなら、問題に関連する領域のみを撮影するようにしてください。

• Django UIの挙動や見た目を変更するパッチを提案する場合は、 必ず 変更前と後のスクリーンショット/スクリーンキャストを添付してください。これらが含まれないチケットは、優先度を付けることが困難です。

• スクリーンショットは他のよいレポート方法を免除するものではありません。URL、コードの抜粋、スクリーンショットの挙動を再現するための詳細な手順が含まれていることを確認してください。

• チケットに UI/UX フラグを設定するのを忘れないでください。このフラグがあると、関係する人たちがチケットをすぐに発見することができます。

機能のリクエスト

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

• Evaluate whether the feature idea requires changes in Django's core. If your idea can be developed as an independent application or module — for instance, you want to support another database engine — we'll probably suggest that you develop it independently. Then, if your project gathers sufficient community support, we may consider it for inclusion in Django.

• Propose the feature in the new feature ideas GitHub project (not in the ticket tracker) by creating a new item in the Idea column. This is where the community and the Steering Council evaluate new ideas for the Django ecosystem. This step is especially important for large or complex proposals. We prefer to discuss any significant changes to Django's core before any development begins. In some cases, a feature may be better suited as a third-party package, where it can evolve independently of Django's release cycle.

• 不足している機能とどのように実装したいのかを明瞭かつ簡潔に記載してください。可能であればコード例も含めてください(機能しなくても問題ありません)。

• なぜ その機能が必要なのか説明してください。最小のユースケースを説明することで、他の人がその機能がどこに適合するのか、既に他の方法で同じ事が達成されていないかを理解する助けになります。

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

Requesting performance optimizations

Reports of a performance regression, or suggested performance optimizations, should provide benchmarks and commands for the ticket triager to reproduce.

See the django-asv benchmarks for more details of Django's existing benchmarks.

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

Whenever possible, we aim for rough consensus. Emoji reactions are used on issues within the new feature ideas GitHub project to track community feedback. The following meanings are assigned to each reaction:

• 👍: I support this feature and would use it

• 👎: I oppose this feature or believe it would cause issues for me or Django

• 😕: I have no strong opinion on this feature

• 🎉: This feature seems like a straightforward and beneficial addition

The Steering Council will regularly review the ideas in the project, moving those with community support through the following stages:

• Idea

• Approved - Idea refinement - Team creation

• In progress

• Working solution - Review - Feedback

• Needs maintainer (Django only)

• Done

Occasionally, discussions on feature ideas or the direction of Django may take place on the Django Forum. These discussions may include informal votes, which 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: "私はこのアイデアが大好きで、強くコミットしています。"

• +0: " 私は OKだと思います。"

• -0: "ワクワクはしないけど、邪魔にはならないと思います。"

• -1: "私は強く反対しますし、このアイデアが現実になるのを見るのは非常に不愉快です。"

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