报告问题和请求新功能¶
Important
请将安全问题 仅 报告给 security@djangoproject.com。 这是一个只对长期以来高度可信的 Django 开发者开放的私人列表，其档案不公开。更多细节，请参见 我们的安全政策。
报告问题¶
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 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.
要了解你创建的工单的生命周期，请参阅 分类工单。
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" 的标记，以便感兴趣的人能找到你的工单。
请求的功能¶
我们一直致力于让 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.
清楚而简洁地描述缺少的功能以及您希望如何实施。 如果可能，请包括示例代码（没有功能也可）。
解释 为什么 你喜欢这个特性。给出一个一个最小可用的例子可以让其他人理解它能被纳入，以及如果有其它办法实现相同的效果。
另请参阅： 记录新功能。
请求性能优化¶
性能回归报告，或建议的性能优化，应提供基准和命令，以便检查员可以重现。
有关 Django 现有基准的更多详细信息，请参阅 django-asv 基准测试。
我们如何作出决定¶
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:
Idea
Approved - Idea refinement - Team creation
In progress
Working solution - Review - Feedback
Needs maintainer (Django only)
Done
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: "看起来没问题。"
-0: "我不觉得特别好，不过也不反对。"
-1: "我强烈反对。如果这个想法变成了现实，我会很不高兴。"
虽然这些投票是非正式的，但它们将被认真对待。在适当的投票期后，如果出现明显的共识，我们将遵循投票结果。
