FAQ:贡献代码

如何为 Django 贡献代码?

感谢反馈!我们已经为这个问题编写了一个详细的文档。参见:doc:Contributing to Django 1.

我几周之前提交了一个工单系统 bug 的修复。为什么忽略我的提议?

别担心:我们不会忽略你!

重要的是要明白,“工单被忽略”和“工单还没有被查看”是有区别的。 Django 的工单系统包含数百个打开的工单,对最终用户功能有不同程度的影响,Django 的开发人员必须检查并确定优先级。

另外:所有的 Django 工作都是由志愿者完成的。因此,我们花在这个框架上的总时间是有限的,它取决于我们的空闲时间,并且每周都会有所不同。如果我们很忙,我们可能无法在 Django 上花费太多的时间,尽管我们不愿如此。

确保工单在签入过程中不被挂起的最佳方法是让它所描述的问题通俗易懂,即便是对相关领域并不熟悉的人也能理解并修复问题:

  • 是否有明确的用以重现 bug 的说明? 是否触及依赖项(如Pillow),contrib 模块或特定数据库?这些说明对于不熟悉它的人是否也足够明确?
  • 如果工单附有多个补充,是否能够明确每个补充是做什么的、哪些补充可以忽略,哪些补充很重要?
  • 补丁是否包括单元测试?如果没有,那么是否可以解释清楚原因?测试可以简洁地表达了问题所在,并显示补丁真的修复了问题。

如果你的补丁没有被加入到 Django,并不意味我们忽视它了——我们只是关闭这个工单。所以如果你的工单一直处于开启状态,也并不意味着我们忽视了你;这只是意味着我们还没来得及看它。

何时以及如何提醒团队我所关注的补丁?

一种获得关注的方式是向邮件列表发送一个礼貌的,适时的消息。为了确保时间合适,你需要留意时间表。如果你在发布截止日期之前发送消息,则不太可能获得您需要的关注。

温和的 IRC 提醒也可以发挥作用——还是如此:如果可能的话,选取一个合适的时间。 例如,在修复 bug 的冲刺期间就是一个不错的时机。

另一种方法获得关注的方法是将几个相关的工单放在一起。当某人坐下来审阅一个他们已经有一段时间没有接触的区域中的bug时,可能需要几分钟的时间来想起该区域代码如何工作的所有细节。如果您将几个小错误的修复集中到一个类似主题的组中,那么您将成为一个有吸引力的目标,因为在一个区域的代码上提速工作的成本可以被用到多个工单上。

请不要通过电子邮件向任何人发邮件或反复提出同样的问题。 这种行为不会让你有任何额外的关注——当然也不会给你带来解决问题所需的关注。

但是我已经提醒你好几遍了,你依然继续忽略我的补丁!

说真的 - 我们不会无视你的。 如果你的补丁没有包含在 Django 的工单,我们将关闭工单。 对于所有其他的工单,我们需要优先考虑我们的努力,这意味着一些工单将在其他人之前解决。

确定 bug 修复优先级的标准之一是对于特定 bug 而言,可能会受到影响的人数。有可能影响许多人的 bug 一般会优先于那些边缘情况下的 bug。

Another reason that bugs might be ignored for while is if the bug is a symptom of a larger problem. While we can spend time writing, testing and applying lots of little patches, sometimes the right solution is to rebuild. If a rebuild or refactor of a particular component has been proposed or is underway, you may find that bugs affecting that component will not get as much attention. Again, this is a matter of prioritizing scarce resources. By concentrating on the rebuild, we can close all the little bugs at once, and hopefully prevent other little bugs from appearing in the future.

Whatever the reason, please keep in mind that while you may hit a particular bug regularly, it doesn't necessarily follow that every single Django user will hit the same bug. Different users use Django in different ways, stressing different parts of the code under different conditions. When we evaluate the relative priorities, we are generally trying to consider the needs of the entire community, instead of prioritizing the impact on one particular user. This doesn't mean that we think your problem is unimportant -- just that in the limited time we have available, we will always err on the side of making 10 people happy rather than making a single person happy.

Back to Top