报告错误和请求功能¶
重要
请**仅**将安全问题报告给security@djangoproject.com。这是一个仅对长期、高度信任的 Django 开发人员开放的私有列表，其档案不公开。有关更多详细信息，请参阅我们的安全策略。
否则，在工单跟踪器上报告错误或请求新功能之前，请考虑以下几点
不要使用工单系统来询问支持问题。为此，请使用django-users邮件列表或#django IRC 频道。
不要在没有在Django 论坛或django-developers邮件列表上达成共识的情况下，重新打开已标记为“不会修复”的问题。
不要使用工单跟踪器进行冗长的讨论，因为它们很可能会丢失。如果某个特定的工单存在争议，请将讨论转移到Django 论坛或django-developers邮件列表。
报告错误¶
写得好的错误报告非常有帮助。但是，使用任何错误跟踪系统都涉及一定程度的开销，因此我们感谢您帮助我们保持工单跟踪器的实用性。特别是
**请**阅读常见问题解答，看看您的问题是否可能是众所周知的问题。
**请**先在django-users或#django上询问，如果您不确定您看到的是否是错误。
**请**编写完整、可重现、具体的错误报告。您必须包含对问题的清晰、简洁的描述，以及一组复制该问题的说明。添加尽可能多的调试信息：代码片段、测试用例、异常回溯、屏幕截图等。一个好的小型测试用例是报告错误的最佳方式，因为它为我们提供了一种有用的方法来快速确认错误。
**请勿**仅发布到django-developers以宣布您已提交错误报告。所有工单都将邮寄到另一个列表django-updates，该列表由开发人员和感兴趣的社区成员跟踪；我们在它们被提交时就能看到它们。
要了解创建工单后的生命周期，请参阅分类工单。
报告用户界面错误和功能¶
如果您的错误或功能请求涉及任何视觉方面的任何内容，则需要遵循一些其他准则
在您的工单中包含屏幕截图，它们是最小测试用例的视觉等效项。展示问题，而不是您对浏览器进行的疯狂自定义。
如果该问题难以使用静态图像展示，请考虑捕获一个简短的屏幕录制。如果您的软件允许，则仅捕获屏幕的相关区域。
如果您提供了一个更改 Django UI 的外观或行为的补丁，则**必须**附加前后屏幕截图/屏幕录制。缺少这些的工单很难让分类人员快速评估。
屏幕截图不会免除您执行其他良好的报告实践。确保包含 URL、代码片段以及有关如何重现屏幕截图中可见的行为的分步说明。
确保在工单上设置 UI/UX 标记，以便相关人员可以找到您的工单。
请求功能¶
我们一直在努力使 Django 变得更好，您的功能请求是其中的关键部分。以下是一些有关如何更有效地提出请求的提示
确保该功能确实需要更改 Django 的核心。如果您的想法可以作为独立的应用程序或模块开发——例如，您想支持另一个数据库引擎——我们可能会建议您独立开发它。然后，如果您的项目获得了足够的社区支持，我们可能会考虑将其包含在 Django 中。
首先在Django 论坛或django-developers邮件列表中请求该功能，而不是在工单跟踪器中请求。如果它在邮件列表中，它将得到更仔细的阅读。对于大规模的功能请求，这一点尤其重要。在实际开始处理 Django 核心的大规模更改之前，我们希望讨论任何此类更改。
清晰简洁地描述缺少的功能以及您希望如何实现它。如果可能，请包含示例代码（非功能性代码也可以）。
解释您为什么想要该功能。解释一个最小的用例将有助于其他人了解它在哪里适用，以及是否已经有其他方法可以实现相同的功能。
如果就该功能达成共识，则创建工单是合适的。在工单描述中包含指向讨论的链接。
与大多数开源项目一样，代码胜于雄辩。如果您愿意自己编写该功能的代码，或者更好的是，如果您已经编写了它，那么它更有可能被接受。在 GitHub 上为 Django 创建分支，创建一个功能分支，并向我们展示您的工作！
另请参阅：记录新功能。
请求性能优化¶
关于性能下降的报告或建议的性能优化应提供基准测试和命令，以便工单分类人员可以复制。
有关 Django 现有基准测试的更多详细信息，请参阅django-asv 基准测试。
我们如何做出决策¶
只要可能，我们都力求达成粗略的共识。为此，我们通常会在django-developers或 Django 论坛上就某个功能进行非正式投票。在这些投票中，我们遵循 Apache 发明并在 Python 本身中使用的投票方式，其中投票以 +1、+0、-0 或 -1 的形式给出。这些投票大致翻译为
+1：“我非常喜欢这个想法，并且坚定地致力于它。”
+0：“对我来说听起来不错。”
-0：“我不太喜欢，但我不会阻挠。”
-1：“我强烈反对，并且非常不希望看到这个想法成为现实。”
尽管这些投票是非正式的，但我们会非常认真地对待它们。在适当的投票期后，如果出现明显的共识，我们将遵循投票结果。
但是，并非总是能够达成共识。如果无法达成共识，或者如果讨论朝着达成共识的方向发展但最终没有得出具体决定，则可能会将决定推迟到指导委员会。
在内部，指导委员会将使用相同的投票机制。如果满足以下条件，则提案将被视为通过
指导委员会成员至少有三个“+1”票。
指导委员会的任何成员都没有“-1”票。
投票应在一周内提交。
由于此过程允许指导委员会的任何成员否决提案，因此“-1”票应附带说明将“-1”转换为至少“+0”需要什么。
有关技术事宜的投票应在django-developers邮件列表或Django 论坛上公开宣布和举行。
