报告问题和请求新功能

重要

请将安全问题 仅 报告给 security@djangoproject.com。 这是一个只对长期以来高度可信的 Django 开发者开放的私人列表，其档案不公开。更多细节，请参见 我们的安全政策。

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

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

报告问题

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

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

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

报告用户界面的 bug 和功能

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

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

请求的功能

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

  • 确认这个特性真的需要改动 Django 的核心。如果你的想法能通过独立的应用或模块实现（比如说你希望支持另一个数据库引擎），我们可能会建议你独立地开发它。而当你的项目获得足够的社区支持时，我们可能会考虑将它纳入 Django。
  • 首先请求| django-developers |列表上的功能，而不是在工单跟踪。 如果它在邮件列表中，将会得到更仔细地阅读。 这对于大规模功能请求来说更为重要。 在实际操作之前，我们倾向在邮件列表上讨论Django核心的任何重大变化。
  • 清楚而简洁地描述缺少的功能以及您希望如何实施。 如果可能，请包括示例代码（没有功能也可）。
  • 解释 为什么 你喜欢这个特性。给出一个一个最小可用的例子可以让其他人理解它能被纳入，以及如果有其它办法实现相同的效果。

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

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

另请参阅：：ref：documenting-new-features。

我们如何作出决定

Whenever possible, we strive for a rough consensus. To that end, we'll often have informal votes on django-developers or the Django Forum about a feature. In these votes we 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: "我强烈反对。如果这个想法变成了现实，我会很不高兴。"

Although these votes are informal, they'll be taken very seriously. After a suitable voting period, if an obvious consensus arises we'll follow the votes.

However, consensus is not always possible. If consensus cannot be reached, or if the discussion toward a consensus fizzles out without a concrete decision, the decision may be deferred to the steering council.

Internally, the steering council will use the same voting mechanism. A proposition will be considered carried if:

  • There are at least three "+1" votes from members of the steering council.
  • There is no "-1" vote from any member of the steering council.

投票应该在一周内提交。

Since this process allows any steering council member to veto a proposal, a "-1" vote should be accompanied by an explanation of what it would take to convert that "-1" into at least a "+0".

Votes on technical matters should be announced and held in public on the django-developers mailing list or on the Django Forum.

« previous | up | next »