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