Reporting bugs and requesting features
否则，在报告错误或请求新功能之前，请考虑以下一般要点：
Reporting bugs
精心编写的错误报告令人难以置信有帮助。然而，使用任何错误跟踪系统有一定的开销，所以您的帮助保持我们的机票跟踪器尽可能有用的赞赏。尤其是：
- 请阅读FAQ，看看您的问题是否是一个众所周知的问题。
- 如果您不确定自己看到的是什么，请 t>在django-users或#django 是一个bug。
- 做写完整，可重复，特定的错误报告。您必须包括对问题的清晰，简明的描述，以及一组复制它的说明。添加尽可能多的调试信息：代码片段，测试用例，异常回溯，屏幕截图等。一个好的小测试用例是报告错误的最好方法，因为它给了我们一个简单的方法来快速确认错误。
- 不要发布到django-developers，以宣布您已提交错误报告。所有票据都会邮寄到另一个列表，django-updates，由开发人员和感兴趣的社区成员跟踪；我们看到他们提交。
要了解票证创建后的生命周期，请参阅Triaging tickets。
Reporting user interface bugs and features
如果您的错误或功能请求涉及任何视觉效果，还有一些额外的指南：
- 在您的故障单中包含屏幕截图，它们与最小测试用例的视觉等效。显示问题，而不是你对浏览器的疯狂自定义。
- 如果使用静态图片难以显示问题，请考虑捕获简短屏幕录像。如果您的软件允许，只捕获屏幕的相关区域。
- 如果您提供修改Django用户界面外观或行为的补丁，则必须在截屏/截屏之前的和之前附加。缺乏这些的门票很难为三人和核心开发商快速评估。
- 截图不会免除你的其他良好的报告做法。请务必加入网址，程式码片段，以及如何重现萤幕撷取画面中显示的行为的逐步指示。
- 确保在票证上设置UI / UX标志，以便感兴趣的各方可以找到您的票证。
Requesting features
我们总是试图让Django更好，你的功能请求是其中的关键部分。以下是有关如何最有效地提出请求的一些提示：
- 确保该功能实际上需要更改Django的核心。如果你的想法可以开发为一个独立的应用程序或模块 - 例如，你想支持另一个数据库引擎 - 我们可能建议你独立开发它。然后，如果您的项目收集足够的社区支持，我们可以考虑将其包含在Django中。
- 首先请在django-developers列表上请求此功能，而不是在故障单跟踪器中。如果它在邮件列表上，它会更仔细地阅读。这对于大规模的特征请求更加重要。我们喜欢讨论对Django的核心在邮件列表上的任何大的变化，然后才真正开始工作。
- 请简要描述缺少的功能是什么，以及您希望如何实现。如果可能，包括示例代码（非功能正常）。
- 解释为什么您需要此功能。在某些情况下，这是显而易见的，但由于Django旨在帮助真正的开发人员完成真正的工作，你需要解释它，如果不明显为什么功能将是有用的。
如果核心开发人员同意该功能，那么创建票证是适当的。在票证描述中包含有关django-developers的讨论的链接。
与大多数开源项目一样，代码会谈。如果你愿意自己编写功能的代码，或者更好的是，如果你已经写了代码，它更有可能被接受。只需在GitHub上fork Django，创建一个功能分支，并向我们展示您的工作！
另请参阅：Documenting new features。
How we make decisions
只要有可能，我们就会争取一个大致的共识。为此，我们通常会在django-developers上对某个功能进行非正式投票。在这些投票中，我们遵循由Apache发明的投票风格，并用于Python本身，其中投票为+1，+ 0，-0或-1。大致翻译，这些票意味着：
- +1：“我喜欢这个想法，我坚决承诺。
- +0：“听起来对我好。
- -0：“我不激动，但我不会站在路上。
- -1：“我强烈不同意，会非常不高兴看到这个想法变成现实。
虽然在django-developers上的这些投票是非正式的，但他们会非常重视。在适当的投票期后，如果有明显的共识，我们将遵循投票。
然而，共识并不总是可能的。如果无法达成共识，或者如果对共识的讨论没有具体决定，任何core team member可以将决策推迟到technical board。
在内部，技术委员会将使用相同的投票机制。如果出现以下情况，则会考虑提出建议：
- 技术委员会成员至少有三个“+1”票。
- 技术委员会的任何成员都没有“-1”投票。
投票应在一周内提交。
由于这个过程允许任何技术委员会成员否决一个提案，“-1”投票应伴随一个解释，将“-1”转换为至少一个“+0”需要什么。
关于技术问题的投票应在django-developers邮件列表上公开并公开。