报告问题和请求新功能¶
Important
请将安全问题 仅 报告给 security@djangoproject.com。 这是一个只对长期以来高度可信的 Django 开发者开放的私人列表，其档案不公开。更多细节，请参见 我们的安全政策。
另外，在向 工单系统 <https://code.djangoproject.com/> 报告问题和请求新功能前，请考虑以下几点：
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.
报告问题¶
编写良好的 Bug 报告是非常有帮助的。不过，在 Bug 追踪系统中处理它们需要一定的开销。因此，我们希望您能尽量提交有用处的 Bug 报告。具体地：
请 先阅读 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.
请 编写完整、可复现的、具体的 bug 报告。你必须简洁且清楚地描述所遇到的问题，并提供复现所需要的步骤。尽可能多地提供代码片段、测试用例、异常回溯、截图等调试信息。一个简洁明了的测试用例是最好的报告 bug 的方法，因为它能让我们快速地确认 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.
要了解你创建的工单的生命周期，请参阅 分类工单。
报告用户界面的 bug 和功能¶
如果你的 bug 或功能请求涉及任何视觉上的东西，则要遵守一些额外的指导：
在工单中包含相当于最小测试样例的截图。请明确说明问题所在，而不是炫耀对浏览器的定制。
如果这个问题很难用图片展示，考虑制作一段简短的屏幕录像。如果你使用的软件支持，最好只录制屏幕上相关的区域。
如果你提交了一个改变 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.
清楚而简洁地描述缺少的功能以及您希望如何实施。 如果可能，请包括示例代码（没有功能也可）。
解释 为什么 你喜欢这个特性。给出一个一个最小可用的例子可以让其他人理解它能被纳入，以及如果有其它办法实现相同的效果。
如果对于该功能达成共识协议，那么创建工单是合适的。在工单描述中包含讨论的链接。
与大多数开源项目一样， code talks。 如果您愿意自己编写该功能的代码，或者更好的是如果您已经编写了代码，则更有可能被接受。 只需在GitHub上 fork Django项目，创建一个功能分支，并向我们展示您的工作！
另请参阅： 记录新功能。
请求性能优化¶
性能回归报告，或建议的性能优化，应提供基准和命令，以便检查员可以重现。
有关 Django 现有基准的更多详细信息，请参阅 django-asv 基准测试。
我们如何作出决定¶
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: "看起来没问题。"
-0: "我不觉得特别好，不过也不反对。"
-1: "我强烈反对。如果这个想法变成了现实，我会很不高兴。"
虽然这些投票是非正式的，但它们将被认真对待。在适当的投票期后，如果出现明显的共识，我们将遵循投票结果。
然而，达成共识并非总是可能的。如果无法达成共识，或者如果朝着共识的讨论没有明确的决定而中断，决策可能会推迟交由 指导委员会 决定。
在内部，指导委员会将使用相同的投票机制。如果一个提案被视为通过，则需要满足以下条件：
如果至少有三位指导委员会成员投出" +1 "的赞同票，提议将被认为通过。
如果没有任何指导委员会成员投出" -1 "的反对票，提议将被认为通过。
投票应该在一周内提交。
由于该过程允许任何指导委员会成员否决提案，" -1 " 票应附带解释如何将该 " -1 " 转化为至少 " +0 "。
Votes on technical matters should be announced and held in public on the Django Forum.
