报告问题和请求新功能

Important

请将安全问题 仅 报告给 security@djangoproject.com。 这是一个只对长期以来高度可信的 Django 开发者开放的私人列表，其档案不公开。更多细节，请参见 我们的安全政策。

报告问题

另外，在向 工单系统 报告问题和请求新功能前，请考虑以下几点：

  • 在工单系统上 搜索 或 自定义查询 ，避免其他人已经提交了相同的问题或功能请求。

  • 不要在工单系统上提出支持问题，请使用 Django 论坛 或 Django Discord服务器。

  • 不要重新打开已标记为“不会修复”的问题，除非在 Django Forum 达成了重新打开的共识。

  • 不要重新打开已标记为“需要新功能流程”的问题，除非通过 GitHub 项目 new feature ideas 引导了问题。

  • 不要在工单系统上进行长篇的讨论，因为它们很可能会被丢失。如果某一工单是具有争议的，请前往 Django 论坛 讨论。

编写良好的 Bug 报告是非常有帮助的。不过，在 Bug 追踪系统中处理它们需要一定的开销。因此，我们希望您能尽量提交有用处的 Bug 报告。具体地：

  • 请 先阅读 FAQ 寻找答案

  • 请 先 在 Django Forum 或 Django Discord服务器 上提问，如果不确定你遇到的问题是否是 Bug。

  • 请 编写完整、可复现的、具体的 bug 报告。你必须简洁且清楚地描述所遇到的问题，并提供复现所需要的步骤。尽可能多地提供代码片段、测试用例、异常回溯、截图等调试信息。一个简洁明了的测试用例是最好的报告 bug 的方法，因为它能让我们快速地确认 bug。

  • 请不要 只因为想要提交bug报告而向 Django Forum 发送邮件。 所有 bug 报告都会被发送到 django-updates 这个邮件列表。开发者和感兴趣的社区成员都会跟踪这个邮件列表，你提交了我们就能看到。

要了解你创建的工单的生命周期，请参阅 分类工作流。

报告用户界面的 bug

如果你的 bug 或功能请求涉及任何视觉上的东西，则要遵守一些额外的指导：

  • 在工单中包含相当于最小测试样例的截图。请明确说明问题所在，而不是炫耀对浏览器的定制。

  • 如果这个问题很难用图片展示，考虑制作一段简短的屏幕录像。如果你使用的软件支持，最好只录制屏幕上相关的区域。

  • 如果你提交了一个改变 Django UI 或行为的补丁，你**必须**附上应用该补丁*前后*的屏幕截图或录像，否则审核人员难以快速评估更改。

  • 即使提供了屏幕截图，也请你仍然遵守其它的惯例。请一定提交相关的 URL 和代码片断，以及复现截图所示行为需要的步骤。

  • 请给你的工单打上 "UI/UX" 的标记，以便感兴趣的人能找到你的工单。

  • 如果问题与可访问性相关，请在适用的情况下链接到相关的 accessibility standard。

请求的功能

我们一直致力于让 Django 变得更好，而你们提出的功能请求是关键的一部分。以下几点能让你更有效地提出功能请求：

  • 确认这个特性真的需要改动 Django 的核心。如果你的想法能通过独立的应用或模块实现（比如说你希望支持另一个数据库引擎），我们可能会建议你独立地开发它。而当你的项目获得足够的社区支持时，我们可能会考虑将它纳入 Django。

  • 在GitHub项目的 new feature ideas 中（而非工单追踪系统）通过在 Idea 栏创建新条目来提议该特性。这里是社区和 管理委员会 评估Django生态系统新想法的地方。对于大型或复杂的提案，这一步尤为重要。我们倾向于在任何开发开始前讨论对Django核心的重大变更。在某些情况下，某功能可能更适合作为第三方包，这样它就能独立于Django的发布周期而演进。

  • 清楚而简洁地描述缺少的功能以及您希望如何实施。 如果可能，请包括示例代码（没有功能也可）。

  • 解释 为什么 你喜欢这个特性。给出一个一个最小可用的例子可以让其他人理解它能被纳入，以及如果有其它办法实现相同的效果。

另请参阅： 记录新功能。

请求性能优化

性能回归报告，或建议的性能优化，应提供基准和命令，以便检查员可以重现。

有关 Django 现有基准的更多详细信息，请参阅 django-asv 基准测试。

我们如何作出决定

只要有可能，我们的目标就是达成大致共识。在Github项目 new feature ideas 中，采用 Emoji 反应来追踪社区反馈。以下是每种反应对应的含义：

  • 👍: 我支持此功能并会使用它

  • 👎: 我反对这个功能，或者认为它会给我或 Django 带来问题

  • 😕: 我对这个功能没有强烈的意见

  • 🎉: 这个功能似乎是一个简单而有益的补充

管理委员会 会定期审核项目中的提案，将获得社区支持的提案推进并通过以下阶段：

  • 提案

  • 已批准 - 提案细化 - 团队创建

  • 进行中

  • 解决方案 - 审核 - 反馈

  • 需要维护者（仅限Django）

  • 完成

偶尔，Django 论坛上可能会讨论功能想法或 Django 的方向。这些讨论可能包括非正式投票，它遵循 Apache 发明并在 Python 上使用的投票风格，投票方式为 +1、+0、-0 或 -1。粗略翻译，这些投票意味着：

  • +1: "我喜欢这个想法，强烈支持。"

  • +0: "看起来没问题。"

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

先决条件

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 平等回归 for instructions.

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

« previous | up | next »