报告 Bug 和请求新功能¶
重要
请仅向 security@djangoproject.com 报告安全问题。这是一个仅对长期且受高度信任的 Django 开发人员开放的私密列表，其归档内容不公开。欲了解更多详情，请参阅 我们的安全政策。
报告 Bug¶
在工单跟踪系统 (ticket tracker) 报告 Bug 之前，请考虑以下几点：
不要使用工单系统提问技术支持问题。请为此使用 Django 论坛 或 Django Discord 服务器。
除非在 Django 论坛上达成共识，否则不要重新开启被标记为“wontfix”（不予修复）的问题。
除非在 新功能建议 (new feature ideas) GitHub 项目中引导过该问题，否则不要重新开启被标记为“needsnewfeatureprocess”（需要新功能流程）的问题。
不要在工单跟踪系统进行冗长的讨论，因为它们很容易丢失。如果某个特定的工单存在争议，请将讨论转移到 Django 论坛。
写得好的 Bug 报告非常有帮助。然而，使用任何 Bug 跟踪系统都需要一定量的管理开销，因此感谢您协助我们尽可能保持工单跟踪系统的有效性。特别是：
请阅读 常见问题解答 (FAQ)，看看您的问题是否已是众所周知的问题。
请首先在 Django 论坛 或 Django Discord 服务器 上询问，如果您不确定所看到的问题是否为 Bug。
请撰写完整、可重现且具体的 Bug 报告。您必须包含对问题的清晰简洁的描述，以及一套复现问题的说明。尽可能添加更多的调试信息：代码片段、测试用例、异常堆栈跟踪、截图等。一个简洁的小型测试用例是报告 Bug 的最佳方式，因为它能让我们快速确认 Bug。
请勿仅为了宣布您提交了 Bug 报告而发布到 Django 论坛。所有的工单都会邮寄到另一个列表 django-updates，该列表由开发人员和感兴趣的社区成员跟踪；我们会看到它们被提交的过程。
要了解工单创建后的生命周期，请参考 工单分诊工作流 (Triage workflow)。
报告用户界面 Bug¶
如果您的 Bug 涉及视觉方面的任何内容，请遵循以下几点额外准则：
在您的工单中包含截图，它们在视觉上等同于最小测试用例。展示问题本身，而不是您对浏览器所做的个性化定制。
如果问题很难用静态图像展示，请考虑录制一个简短的截屏视频。如果您的软件允许，请仅截取屏幕的相关区域。
如果您提供的补丁改变了 Django 用户界面的外观或行为，您必须附上修改前和修改后的截图/截屏视频。缺乏这些信息的工单很难让分诊人员快速评估。
截图并不能免除您遵循其他良好的报告习惯。请确保包含 URL、代码片段以及重现截图中所见行为的分步说明。
确保在工单上设置 UI/UX 标记，以便相关方可以找到您的工单。
如果问题与可访问性相关，请在适用时链接到相关的 可访问性标准。
请求新功能¶
我们一直在努力改进 Django，您的功能请求是其中的重要部分。以下是一些如何最有效地提出请求的建议：
评估该功能想法是否需要更改 Django 的核心代码。如果您的想法可以作为独立的应用程序或模块开发——例如，您想支持另一种数据库引擎——我们可能会建议您独立开发它。然后，如果您的项目获得了足够的社区支持，我们可以考虑将其纳入 Django。
请在 新功能建议 (new feature ideas) GitHub 项目中（而不是在工单跟踪系统中）通过在 Idea（想法）列创建一个新条目来提出该功能。这是社区和 指导委员会 (Steering Council) 评估 Django 生态系统新想法的地方。这一步对于大型或复杂提案尤其重要。我们倾向于在开始任何开发之前先讨论 Django 核心的任何重大变更。在某些情况下，功能可能更适合作为第三方包，这样它可以独立于 Django 的发布周期进行演进。
清晰且简洁地描述缺失的功能是什么，以及您希望如何实现它。如果可能，请附上示例代码（即使不是功能性的也可以）。
解释为什么您想要这个功能。解释一个最小的使用案例将有助于他人理解它的适配场景，以及是否已经有其他方法可以实现同样的目的。
另请参阅：记录新功能。
请求性能优化¶
关于性能回退的报告，或建议的性能优化，应提供基准测试和供工单分诊人员复现的命令。
有关 Django 现有基准测试的更多详细信息，请参阅 django-asv 基准测试。
我们如何做出决策¶
尽可能地，我们追求达成共识。表情符号反应被用于 新功能建议 (new feature ideas) GitHub 项目中的议题上，以跟踪社区反馈。每种反应对应的含义如下：
👍：我支持这个功能，并且我会使用它。
👎：我反对这个功能，或者认为它会给我或 Django 带来问题。
😕：我对这个功能没有强烈意见。
🎉：这个功能似乎是一个直接且有益的补充。
指导委员会 (Steering Council) 将定期审查项目中的想法，将那些获得社区支持的想法推进到以下阶段：
Idea（想法）
Approved - Idea refinement - Team creation（已批准 - 完善想法 - 组建团队）
In progress（进行中）
Working solution - Review - Feedback（工作方案 - 评审 - 反馈）
Needs maintainer (Django only)（需要维护者，仅限 Django）
Done（完成）
有时，关于功能想法或 Django 方向的讨论可能会在 Django 论坛上进行。这些讨论可能包括非正式投票，遵循 Apache 发明并在 Python 自身中使用的投票风格，投票方式为 +1, +0, -0 或 -1。粗略翻译，这些票数的含义是：
+1：“我喜欢这个想法，我强烈支持它。”
+0：“我觉得还可以。”
-0：“我不太兴奋，但我不会阻碍它。”
-1：“我强烈反对，如果这个想法成为现实，我会很不高兴。”
虽然这些投票是非正式的，但会非常认真地对待。经过适当的投票期，如果出现明显的共识，我们将遵循投票结果。
如何测试 Django 的预发布版本¶
测试预发布版本是为 Django 做出贡献的好方法。早期测试人员有助于在最终发布前捕捉 Bug，确保每个人都有更顺畅的升级体验。
先决条件¶
在测试预发布版本之前，重要的是确保您的项目在最新的 Django 稳定版本上运行顺畅。这样，任何性能回退都可以归因于预发布版本。有关如何更新的说明，请参见 如何将 Django 升级到新版本 指南。
为确保您的项目准备就绪，您还应该：
阅读发行说明： 查看即将发布版本的 发行说明，了解已弃用功能的升级路径或有关轻微向后不兼容变更的信息。
解决弃用警告： 在启用弃用警告的情况下运行您的测试，以了解所需的后续操作。
$ python -Wa manage.py test
测试您的项目¶
您可以使用 pip 安装最新的预发布版本：
$ python -m pip install --pre Django
安装完成后，运行您项目的测试套件。除了检查测试是否通过外，请尝试以下操作：
检查依赖项支持： 通过在 PyPI 上检查 Django 版本分类器来确定主要依赖项是否支持新版本。由于这些项目也重视早期的 Bug 报告，不要让缺乏支持阻止您进行测试。
监控性能： 您可以使用
test --durations标志运行测试，以识别潜在的性能回退。在 CI 中自动化测试： 考虑使用预发布版本运行您的持续集成 (CI) 流水线。
手动测试： 虽然自动化测试很好，但手动测试应用程序的主要工作流程是验证与新版本兼容性的重要部分。
报告问题¶
如果您发现 Bug，请通过 Django 问题跟踪器 报告，以便在最终发布前修复它。在创建工单时，请务必将 Django 版本字段设置为您正在测试的确切预发布版本。
如果您怀疑存在性能回退，报告导致该回退的具体提交记录会很有帮助。有关说明，请参阅 二分法查找性能回退 (Bisecting a regression)。
您还可以通过 Django 论坛 上的 预发布 (Pre-releases) 分类讨论任何问题或分享反馈。
