报告问题和请求新功能¶
重要
请将安全问题 仅 报告给 security@djangoproject.com。 这是一个只对长期以来高度可信的 Django 开发者开放的私人列表,其档案不公开。更多细节,请参见 我们的安全政策。
另外,在向 工单系统 <https://code.djangoproject.com/> 报告问题和请求新功能前,请考虑以下几点:
- 在工单系统上 搜索 或 自定义查询 ,避免其他人已经提交了相同的问题或功能请求。
- 不要在工单系统上提出支持问题,请使用 |djang-users| 邮件列表或 #django IRC 频道。
- 不要重新打开已标记为“不修复”的问题,除非在 Django Forum 或 django-developers 列表上找到了重新打开的共识。
- 请不要在票务跟踪系统中进行冗长的讨论,因为它们很可能会被遗忘。如果某个特定的问题具有争议性,请将讨论移到 Django Forum 或 django-developers 列表中。
报告问题¶
编写良好的 Bug 报告是非常有帮助的。不过,在 Bug 追踪系统中处理它们需要一定的开销。因此,我们希望您能尽量提交有用处的 Bug 报告。具体地:
- 请 先阅读 FAQ 寻找答案
- 请 先 在 django-users 或 #django 上提问,如果不确定你遇到的问题是否是 Bug。
- 请 编写完整、可复现的、具体的 bug 报告。你必须简洁且清楚地描述所遇到的问题,并提供复现所需要的步骤。尽可能多地提供代码片段、测试用例、异常回溯、截图等调试信息。一个简洁明了的测试用例是最好的报告 bug 的方法,因为它能让我们快速地确认 bug。
- 请不要 只因为想要提交bug报告而向 django-developers 发送邮件。 所有 bug 报告都会被发送到 django-updates 这个邮件列表。开发者和感兴趣的社区成员都会跟踪这个邮件列表,你提交了我们就能看到。
要了解你创建的工单的生命周期,请参阅 分类工单。
报告用户界面的 bug 和功能¶
如果你的 bug 或功能请求涉及任何视觉上的东西,则要遵守一些额外的指导:
- 在工单中包含相当于最小测试样例的截图。请明确说明问题所在,而不是炫耀对浏览器的定制。
- 如果这个问题很难用图片展示,考虑制作一段简短的屏幕录像。如果你使用的软件支持,最好只录制屏幕上相关的区域。
- 如果你提交了一个改变 Django UI 或行为的补丁,你**必须**附上应用该补丁*前后*的屏幕截图或录像,否则审核人员难以快速评估更改。
- 即使提供了屏幕截图,也请你仍然遵守其它的惯例。请一定提交相关的 URL 和代码片断,以及复现截图所示行为需要的步骤。
- 请给你的工单打上 "UI/UX" 的标记,以便感兴趣的人能找到你的工单。
请求的功能¶
我们一直致力于让 Django 变得更好,而你们提出的功能请求是关键的一部分。以下几点能让你更有效地提出功能请求:
- 确认这个特性真的需要改动 Django 的核心。如果你的想法能通过独立的应用或模块实现(比如说你希望支持另一个数据库引擎),我们可能会建议你独立地开发它。而当你的项目获得足够的社区支持时,我们可能会考虑将它纳入 Django。
- 首先在 Django Forum 或 django-developers 列表上请求该功能,而不是在票务跟踪系统上。如果在邮件列表上提出请求,它将会被更仔细地阅读。对于大规模的功能请求,这更加重要。在实际着手工作之前,我们喜欢讨论对 Django 核心的任何重大更改。
- 清楚而简洁地描述缺少的功能以及您希望如何实施。 如果可能,请包括示例代码(没有功能也可)。
- 解释 为什么 你喜欢这个特性。给出一个一个最小可用的例子可以让其他人理解它能被纳入,以及如果有其它办法实现相同的效果。
如果对于该功能达成共识协议,那么创建工单是合适的。在工单描述中包含讨论的链接。
与大多数开源项目一样, code talks。 如果您愿意自己编写该功能的代码,或者更好的是如果您已经编写了代码,则更有可能被接受。 只需在GitHub上 fork Django项目,创建一个功能分支,并向我们展示您的工作!
另请参阅: 记录新功能。
Requesting performance optimizations¶
Reports of a performance regression, or suggested performance optimizations, should provide benchmarks and commands for the ticket triager to reproduce.
See the django-asv benchmarks for more details of Django's existing benchmarks.
我们如何作出决定¶
只要有可能,我们就会努力争取达成大致的共识。为此,我们经常在|django-developers|或Django论坛上对某项功能进行非正式投票。在这些投票中,我们遵循由Apache发明并在Python上使用的投票方式,投票结果为+1、+0、-0或-1。粗略地翻译一下,这些投票意味着:
- +1: "我喜欢这个想法,强烈支持。"
- +0: "看起来没问题。"
- -0: "我不觉得特别好,不过也不反对。"
- -1: "我强烈反对。如果这个想法变成了现实,我会很不高兴。"
虽然这些投票是非正式的,但它们将被认真对待。在适当的投票期后,如果出现明显的共识,我们将遵循投票结果。
然而,达成共识并非总是可能的。如果无法达成共识,或者如果朝着共识的讨论没有明确的决定而中断,决策可能会推迟交由 指导委员会 决定。
在内部,指导委员会将使用相同的投票机制。如果一个提案被视为通过,则需要满足以下条件:
- 如果至少有三位指导委员会成员投出" +1 "的赞同票,提议将被认为通过。
- 如果没有任何指导委员会成员投出" -1 "的反对票,提议将被认为通过。
投票应该在一周内提交。
由于该过程允许任何指导委员会成员否决提案," -1 " 票应附带解释如何将该 " -1 " 转化为至少 " +0 "。
在技术事项上的投票应该在 django-developers 邮件列表或 Django 论坛 上公开宣布并举行。