报告问题和请求新功能P

重要

安全问题请**只**向 security@djangoproject.com 报告。此邮件列表是私密的,只向资历深且高度可信的 Django 开发者开放,其存档不会被公开。如需要更多细节,请前往 :doc:`我们的安全策略 </internals/security>`页面查看。

另外,在向 工单系统 <https://code.djangoproject.com/> 报告问题和请求新功能前,请考虑以下几点:

  • 在工单系统上`搜索`或`自定义查询`,避免其他人已经提交了相同的问题或功能请求。
  • 不要在工单系统上提出支持问题,请使用 |djang-users| 邮件列表或 `#django`_IRC频道。
  • 如果没有在 django-developers 上达成一致,不要重新开启已被标记为“不会修复”的问题。
  • 不要在工单系统上进行长篇的讨论,因为它们很可能会被丢失。如果某一工单是具有争议的,请前往 |django-developer| 讨论。

报告问题P

编写良好的 Bug 报告是非常有帮助的。不过,在 Bug 追踪系统中处理它们需要一定的开销。因此,我们希望您能尽量提交有用处的 Bug 报告。具体地:

  • **请**先阅读 :doc:`FAQ </faq/index>`寻找答案
  • 先在 django-users#django 上提问,如果不确定你遇到的问题是否是 Bug。
  • 编写完整、可复现的、具体的 bug 报告。你必须简洁且清楚地描述所遇到的问题,并提供复现所需要的步骤。尽可能地提供代码片段、测试用例、异常回溯等调试信息。一个小测试用例是最好的报告 bug 的方法,因为它能让我们快速地确认 bug。
  • 请不要django-developers 发帖,如果你只是想宣告你提交了一个 bug 报告。 所有 bug 报告都会被发送到 django-updates 这个邮件列表。开发者和感兴趣的社区成员都会跟踪这个邮件列表,你提交了我们就能看到。

要了解你创建的工单的生命周期,请参阅:doc: triaging-tickets

报告用户界面的 bug 和功能P

如果你的 bug 或功能请求涉及任何视觉上的东西,则要遵守一些额外的指导:

  • 包含在你的工单中的相当于最小测试样例的截图。提出这个问题,不要疯狂地对浏览器进行定制。
  • 如果这个问题很难用图片展示,考虑制作一段简短的屏幕录像。如果你使用的软件支持,最好只录制屏幕上相关的区域。
  • 如果你提交一个改变 Django UI 的外观或行为的补丁,你 必须 附上应用该补丁之前及之后的屏幕截图或录像,否则审核人员难以快速地进行评估。
  • 即使提供了屏幕截图,也请你仍然遵守其它的惯例。请一定提交相关的 URL 和代码片断,以及复现截图所示行为需要的步骤。
  • 请给你的工单打上 "UI/UX" 的标记,以便感兴趣的人能找到你的工单。

请求的功能P

我们一直致力于让 Django 变得更好,而你们提出的功能请求是关键的一部分。以下几点能让你更有效地提出功能请求:

  • 确认这个特性真的需要改动 Django 的核心。如果你的想法能通过独立的应用或模块实现(比如说你希望支持另一个数据库引擎),我们可能会建议你独立地开发它。而当你的项目获得足够的社区支持时,我们可能会考虑将它纳入 Django。
  • 首先请求| django-developers |列表上的功能,而不是在工单跟踪。 如果它在邮件列表中,将会得到更仔细地阅读。 这对于大规模功能请求来说更为重要。 在实际操作之前,我们倾向在邮件列表上讨论Django核心的任何重大变化。
  • 清楚而简洁地描述缺少的功能以及您希望如何实施。 如果可能,请包括示例代码(没有功能也可)。
  • 解释*为什么*你想要这个功能。 在某些情况下,这是显而易见的,但由于Django旨在帮助真正的开发人员完成实际工作,因此您需要对其进行解释,防止出现不明显为什么该功能会有用的情况。

如果对该功能达成共识,则创建工单是合适的。 在| django-developers |工单描述中加入讨论链接 。

与大多数开源项目一样, code talks。 如果您愿意自己编写该功能的代码,或者更好,如果您已经编写了代码,则更有可能被接受。 只需在GitHub上 fork Django项目,创建一个功能分支,并向我们展示您的工作!

另请参阅::ref:documenting-new-features

我们如何作出决定P

有可能时,我们会尽力达成共识。我们经常会在 django-developers 对某个特性进行非正式的投票。这些投票遵循的投票规则由 Apache 发明,并被 Python 本身使用。此规则中投票者可以投 +1、+0、-0或-1。它们的大概含义如下:

  • +1: "我喜欢这个想法,强烈支持。"
  • +0: "看起来没问题。"
  • -0: "我不觉得特别好,不过也不反对。"
  • -1: "我强烈反对。如果这个想法变成了现实,我会很不高兴。"

尽管 django-developers 上的投票是非正式的, 它们还是会被认真地对待。 在合适的投票期过后,如果有明显的共识,我们会遵循它。

然而,并不是每次都能达成共识。如果不能达成共识,或者如果没有做出具体决定而达成共识的讨论失败,则可以将决定推迟到::ref:`technical board `.。

在内部,技术委员会将使用相同的投票机制。如果出现以下情况,将视为提议:

  • 技术委员会成员至少有三张 “+1” 的投票。
  • 技术委员会成员没有“-1”投票。

投票应该在一周内提交。

由于此过程允许任何技术委员会成员否决提案,因此“-1”投票应伴随将该“-1”转换为至少“+0”的内容。

关于技术问题的投票应在| django-developers |邮件列表上公布并公开举行。