# Django 6.0.7 ドキュメント

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

重要

Please report security issues only to `security@djangoproject.com`. This is a private list only open to long-time, highly trusted Django developers, and its archives are not public. For further details, please see 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 reopen issues that have been marked "needsnewfeatureprocess" without shepherding an issue through the new feature ideas GitHub project.

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

To understand the lifecycle of your ticket once you have created it, refer to トリアージのワークフロー.

### 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 フラグを設定するのを忘れないでください。このフラグがあると、関係する人たちがチケットをすぐに発見することができます。

- If the issue relates to accessibility, please link to the relevant accessibility standard if applicable.

## 機能のリクエスト

我々は常に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:

- アイデア

- Approved - Idea refinement - Team creation

- 進行中

- Working solution - Review - Feedback

- Needs maintainer (Django only)

- 完了

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: "私は強く反対しますし、このアイデアが現実になるのを見るのは非常に不愉快です。"

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

## How to test pre-release versions of Django

Testing pre-releases is a great way to contribute to Django. Early testers help catch bugs before the final release, ensuring a smoother upgrade experience for everyone.

### Prerequisites

Before testing a pre-release, it is important that your project is running smoothly on the latest stable release of Django. That way, any regressions can be attributed to the pre-release. See the Django の新しいバージョンへの更新 guide for instructions on getting up to date.

To ensure your project is ready, you should also:

- Read the release notes: Review the リリースノート for the upcoming version to learn about upgrade paths for deprecated features or about minor backward-incompatible changes.

- Resolve deprecation warnings: Run your tests with deprecation warnings enabled to become aware of required follow-up actions:

      $ python -Wa manage.py test

### Testing your project

You can install the latest pre-release using `pip`:

    $ python -m pip install --pre Django

Once installed, run your project's test suite. Rather than just checking if tests pass, try the following:

- Check dependency support: Determine whether major dependencies support the new version by checking Django version classifiers on PyPI. Since those projects also value early bug reports, don't let a lack of support prevent you from testing.

- Monitor performance: You can run your tests with the `test --durations` flag to identify potential performance regressions.

- Automate tests in CI: Consider running your Continuous Integration (CI) pipeline with the pre-release version.

- Test manually: While automated tests are great, manually testing your application's main workflows is an important part of verifying compatibility with a new release.

### Reporting issues

If you discover a bug, please report it via the Django issue tracker so it can be fixed before the final release. When creating the ticket, be sure to set the Django version field to the exact pre-release version you are testing.

If you suspect a regression, it's helpful to report the specific commit that caused it. See リグレッションの bisect for instructions.

You can also discuss any issues or share feedback in the Pre-releases category on the Django Forum.