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

バグレポート¶

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

• あなたの疑問が一般的なものである可能性がある際は、 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のライフサイクルを理解するため、ドキュメントの チケットをトリアージする を参照してください。

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

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

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

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

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

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

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

機能のリクエスト¶

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

• リクエストする機能は、本当にDjangoコアの改修が必要かどうか確認してください。例えば、データベースエンジンの追加要望のような、独立したアプリケーションやモジュールの開発で対応可能な場合は、独立した開発をお勧めします。その後、あなたのプロジェクトがコミュニティーから十分に支持されれば、Djangoに含めるか検討することになります。

• First request the feature on the Django Forum, not in the ticket tracker. It'll get read more closely and reach a larger audience. 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.

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

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

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

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

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

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 strive for a rough consensus. To that end, we'll often have informal votes on 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: "私はこのアイデアが大好きで、強くコミットしています。"

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

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

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

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

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

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

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

• 運営委員会のどのメンバーからも "-1" の票が入らないこと。

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

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

Votes on technical matters should be announced and held in public on the Django Forum.