对新贡献者的建议

新来的贡献者,不知道该怎么办? 想要提供帮助但是不知道如何开始? 那这就是为你准备的部分。

Get up and running!

如果您是 Django 新的贡献者,那么 :文档:`/intro/contributing` 教程将为您介绍这些工具和工作流程。

This page contains more general advice on ways you can contribute to Django, and how to approach that.

如果你正在寻找关于代码贡献的细节参考,参见 编写代码 文档。

快速入门

从这些任务开始,去发现 Django 的开发过程。

  • 分类工单

    如果一个`未审查的工单`_报告了一个错误,请尝试验证并重现它。如果您可以重现它并且它似乎是有效的,写一条记录以表明你确认了该错误并接受该工单。确保该工单归档在正确的组件区域。即使你不去修复bug本身,你也可以写一个用于测试bug的行为的补丁。查看更多内容请点击:ref:“我如何在分类方面帮忙”

  • 寻找已被接受的工单并审查补丁,以建立对代码库和流程的熟悉

    如果修补程序需要文档或测试,请标记相应的标志。查看补丁程序所做的更改,并留意与旧版但仍受支持的Python不兼容的语法。 :doc:`Run the tests ` 并确保它们通过。在可能的和相关的地方,在SQLite之外的数据库上尝试它们。留下评论和反馈!

  • 更新旧的的修补程序

    通常情况下,代码库会在提交补丁和审阅补丁之间发生变化。确保它仍然干净地应用,并按预期运行。更新补丁既有用又重要!更多信息请参见代码 提交补丁

  • 撰写一些文档

    Django的文档很好,但它总是可以改进的。你发现打字错误了吗?你认为有什么需要澄清的吗?继续并建议一个文档修补程序!另请参阅指南 编写文档

    备注

    `报告页`_包含了许多有用的Trac查询链接,包括一些像上面建议的那样对分类工单和审查补丁有用的链接。

  • 签署贡献者许可协议

    您编写的代码属于您或您的雇主。 如果您的贡献超过一至两行代码,则需要签署 CLA 。 有关更详尽的解释,请参阅 Contributor License Agreement FAQ”。

方针

作为大型项目的新手,很容易感到沮丧。 这里有一些建议可以使你在 Django 上的工作更加有用、 有收获。

  • 选择一个您关心的,您熟悉的或您想了解的主题区

    你不必已是你想要工作的领域的专家; 您将通过对代码的持续贡献成为专家。

  • Analyze tickets’ context and history

    Trac不是绝对的;上下文和名词一样重要。在阅读Trac时,你需要考虑到账户谁说了什么,什么时候说的。两年前对一个想法的支持并不意味着这个想法还会得到支持。您还需要注意哪些人没有发言—例如,如果一位有经验的贡献者最近没有参与讨论,那么这份工单可能就不需要Django支持。

  • 从小的地方开始

    在小问题上得到反馈比在大问题上得到反馈要容易得多。请参阅 easy pickings

  • If you’re going to engage in a big task, make sure that your idea has support first

    这意味着在您解决问题之前让其他人确认一个bug是真实的,并确保在您开始实现一个建议的特性之前有一个共识。

  • Be bold! Leave feedback!

    有时候,把你的观点向全世界发表,说“这个工单是正确的”或者“这个补丁需要工作”,这可能会让人害怕,但这是项目向前推进的唯一途径。广泛的Django社区的贡献最终会比任何一个人的贡献产生更大的影响。没有**你**我们做不到!

  • 在标记要接收的提议时要小心

    如果你真的不确定一张工单是否准备好了,不要这样标记。留下注释,让别人知道你的想法。如果你基本上是肯定的,但不是完全确定,你也可以试着问一下IRC,看看是否有人能证实你的怀疑。

  • 等待反馈,并对收到的反馈做出回应

    专注于一两张工单,从头到尾看完,然后重复。短期途径接手很多工单,让一些工单在半路上掉下来,这样做的结果是弊大于利。

  • Be rigorous

    当我们说 “PEP 8, 并且必须有文档和测试” 时,我们是认真的。如果补丁没有文档和测试,最好有一个好的理由。像“我找不到这个特性的任何现有测试”这样的论据不会有多少说服力——虽然这可能是真的,但这意味着你要为这个特性编写最初的测试,而不是完全通过编写测试获得通过。

  • Be patient

    It’s not always easy for your ticket or your patch to be reviewed quickly. This isn’t personal. There are a lot of tickets and pull requests to get through.

    Keeping your patch up to date is important. Review the ticket on Trac to ensure that the Needs tests, Needs documentation, and Patch needs improvement flags are unchecked once you’ve addressed all review comments.

    Remember that Django has an eight-month release cycle, so there’s plenty of time for your patch to be reviewed.

    Finally, a well-timed reminder can help. See contributing code FAQ for ideas here.