给新贡献者的建议 — Django 文档
给新贡献者的建议
新的贡献者，不知道该怎么做？ 想提供帮助但不知道如何开始？ 这是给你的部分。
第一步
从这些步骤开始，探索 Django 的开发过程。
分诊票
如果 未审核票证 报告错误，请尝试重现它。 如果您可以重现它并且它看起来有效，请记下您确认了错误并接受了票证。 确保工单在正确的组件区域下归档。 考虑编写一个补丁来添加对错误行为的测试，即使您不修复错误本身。 查看更多信息 我如何帮助分类？
寻找被接受的票并查看补丁以熟悉代码库和流程
如果补丁需要文档或测试，请标记适当的标志。 查看补丁所做的更改，并留意与较旧但仍受支持的 Python 版本不兼容的语法。 运行测试并确保它们通过。 在可能和相关的情况下，在 SQLite 以外的数据库上试用它们。 留下评论和反馈！
使旧补丁保持最新
通常情况下，代码库会在补丁提交和审查之间发生变化。 确保它仍然干净地应用并按预期运行。 更新补丁既有用又重要！ 查看更多关于 提交补丁 。
写一些文档
Django 的文档很棒，但它总是可以改进的。 你发现错别字了吗？ 你认为应该澄清一些事情吗？ 继续并建议一个文档补丁！ 另请参阅有关 编写文档 的指南。
笔记
报告页面 包含指向许多有用的 Trac 查询的链接，其中包括一些对分类故障单和审查上述建议的补丁有用的链接。
签署贡献者许可协议
您编写的代码属于您或您的雇主。 如果你的贡献超过一两行代码，则需要签署CLA。 请参阅 贡献者许可协议常见问题解答 以获得更详尽的解释。
指南
作为大型项目的新手，很容易遇到挫折。 这里有一些建议可以让你在 Django 上的工作更有用和更有价值。
选择您关心、熟悉或想了解的学科领域
您不必成为您想要从事的领域的专家； 通过对代码的持续贡献，您将成为专家。
分析工单的上下文和历史
Trac 不是绝对的； 上下文和文字一样重要。 阅读 Trac 时，您需要考虑谁说了什么，以及什么时候说的。 两年前支持一个想法并不一定意味着这个想法仍然会得到支持。 您还需要注意谁 没有 发言——例如，如果一位经验丰富的贡献者最近没有参与讨论，那么票证可能不具备进入 Django 所需的支持。
从小处着手
获得对小问题的反馈比对大问题更容易。 请参阅 轻松挑选 。
如果你要从事一项大任务，首先要确保你的想法得到支持
这意味着在您修复问题之前让其他人确认错误是真实的，并确保在您开始实施之前就提议的功能达成共识。
大胆点！ 留下反馈！
有时将您的意见告诉全世界并说“这张票是正确的”或“这个补丁需要工作”可能会很可怕，但这是项目向前推进的唯一途径。 广大 Django 社区的贡献最终比任何人的影响都大得多。 没有你，我们做不到！
将物品标记为“准备登机”时要小心谨慎
如果您真的不确定票是否准备好，请不要将其标记为这样。 而是发表评论，让其他人知道您的想法。 如果您基本确定，但不完全确定，您也可以尝试在 IRC 上询问是否有其他人可以证实您的怀疑。
等待反馈，并回应您收到的反馈
专注于一两张票，从头到尾看一遍，然后重复。 接受大量门票并让一些门票掉在路边的霰弹枪方法最终弊大于利。
严谨
当我们说“PEP 8，并且必须有文档和测试”时，我们是认真的。 如果补丁没有文档和测试，最好有一个很好的理由。 诸如“我找不到此功能的任何现有测试”之类的论点并没有多大意义——虽然它可能是真的，但这意味着您有一个额外重要的工作是为该功能编写第一个测试，而不是您从完全编写测试中获得通过。
常见问题
我关心的这张票已经被忽略了几天/几周/几个月！ 我能做些什么来让它承诺？
首先，这不是个人的。 Django 完全由志愿者开发（除了 Django 伙伴），有时人们只是没有时间。 最好的办法是向 django-developers 邮件列表发送一个温和的提醒，要求对票进行审查，或者在
#django-devIRC 频道中提出。我确定我的票绝对是 100% 完美的，我可以自己将其标记为 RFC 吗？
简短的回答：没有。 让另一只眼睛盯着一张票总是更好。 如果您在获得第二组眼睛时遇到问题，请参阅上面的问题 1。
