新的贡献者，不知道该怎么办？想要帮助，但只是不知道如何开始？这是你的部分。
开始这些简单的任务，以发现Django的开发过程。
签署贡献者许可协议
您写的代码属于您或您的雇主。如果您的贡献超过一行或两行代码，则需要签署CLA。有关详细说明，请参阅贡献者许可协议常见问题。
分流票
如果未审核的票证报告错误，请尝试重现。如果你可以重现它，它似乎有效，记下你确认错误并接受票。确保票据存储在正确的组件区域下。考虑写一个补丁，为bug的行为添加一个测试，即使你不修复bug本身。有关详情，请参阅How can I help with triaging?
查找接受的故障单，并查看修补程序以熟悉代码库和过程
如果补丁需要文档或测试，请标记相应的标志。查看修补程序所做的更改，并留意与旧版本但仍支持的Python版本不兼容的语法。运行测试并确保它们在您的系统上传递。在可能和相关的情况下，在除SQLite之外的数据库上尝试。留下评论和反馈！
保持最新的补丁
通常，代码库将在提交的修补程序和审核时间之间更改。确保它仍然适用，并按预期工作。简单地更新补丁既有用又重要！请参阅Submitting patches。
编写一些文档
Django的文档是伟大的，但它可以随时改进。你找到了错字吗？你认为应该澄清什么吗？继续并建议文档补丁！另请参阅Writing documentation指南，特别是Improving the documentation的提示。
注意
报告页包含许多有用的Trac查询的链接，其中包括几个可用于按上述建议对故障单进行分类和审查补丁的情况。
作为一个大型项目的新手，很容易感到沮丧。这里有一些建议，使您的Django上的工作更有用和有益的。
选择您关心的，熟悉的或想要了解的主题区域
你不必是一个专家在你想工作的领域；您将通过您对代码的持续贡献成为一名专家。
分析票证的上下文和历史记录
Trac不是绝对的；语境与语言一样重要。当读Trac时，你需要考虑谁说的事情，当他们说。两年前支持一个想法并不一定意味着这个想法仍然会有支持。您还需要注意谁没有说话 - 例如，如果核心团队成员最近没有参与讨论，那么票证可能不需要支持树干。
开始小
在一个小问题上比在一个大问题上获得反馈更容易。请参阅轻松选择。
如果你打算从事一项很重要的工作，请先确认你的想法是否有支持
这意味着在解决问题之前让别人确认错误，并确保核心团队在实施之前支持提议的功能。
大胆！留下反馈！
有时，将你的意见告诉世界并说“这张票是正确的”或“这个补丁需要工作”可能是可怕的，但它是项目向前迈进的唯一方式。广泛的Django社区的贡献最终比核心团队的影响大得多。我们不能不用你！
在标记物品准备就绪时，请小心谨慎
如果你真的不确定票是否准备好了，不要标记为这样。发表评论，让别人知道你的想法。如果你确定，但不完全确定，你也可以尝试问IRC，看看是否有人可以确认你的怀疑。
等待反馈，并回复您收到的反馈
专注于一张或两张票，从开始到结束，看他们，并重复。猎枪的方法，拍摄很多票，让一些跌倒在路边结束了更多的危害比好。
要严谨
当我们说“ PEP 8，并且必须有文档和测试”时，我们是指它。如果补丁没有文档和测试，最好有一个很好的理由。像“我找不到任何现有的测试这个功能”这样的参数不承担很大的重量 - 虽然这可能是真的，这意味着你有非常重要的工作，写该功能的第一个测试，而不是得到一个通过从书面测试完全。
我关心的这张票已被忽略了几天/周/月！我该怎么办才能让它提交？
首先，它不是个人的。Django完全由志愿者（即使是核心团队）开发，有时候人们没有时间。最好的办法是向django-developers邮件列表发送温和提醒，要求对该票进行审核，或者在＃django-dev IRC频道中提出。
我相信我的票是绝对完美的，我可以标记为RFC自己吗？
简答：不。总是最好在票上得到另一组眼睛。如果您无法获得第二组眼睛，请参阅上面的问题1。
2015年5月13日