---
title: "对新贡献者的建议"
version: 3.1
locale: zh-hans
source: https://docs.djangoproject.com/zh-hans/3.1/internals/contributing/new-contributors/
canonical: https://djangodocs.dev/zh-hans/3.1/internals/contributing/new-contributors/
---
# 对新贡献者的建议

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

> **Get up and running!**
>
> 如果您是 Django 新的贡献者，那么  教程将为您介绍这些工具和工作流程。

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

If you are looking for a reference on the details of making code contributions,
see the [编写代码](/zh-hans/3.1/internals/contributing/writing-code/) documentation.

## 快速入门

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

- **分类工单**

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

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

  通常情况下，代码库会在提交补丁和审阅补丁之间发生变化。确保它仍然干净地应用，并按预期运行。更新补丁既有用又重要！更多信息请参见代码 [提交补丁](/zh-hans/3.1/internals/contributing/writing-code/submitting-patches/) 。
- **撰写一些文档**

  Django的文档很好，但它总是可以改进的。你发现打字错误了吗？你认为有什么需要澄清的吗？继续并建议一个文档修补程序！另请参阅指南 [编写文档](/zh-hans/3.1/internals/contributing/writing-documentation/) 。

  > **Note**
  >
  > 报告页\`\_包含了许多有用的Trac查询链接，包括一些像上面建议的那样对分类工单和审查补丁有用的链接。
- **签署贡献者许可协议**

  您编写的代码属于您或您的雇主。 如果您的贡献超过一至两行代码，则需要签署 [CLA](https://www.djangoproject.com/foundation/cla/) 。 有关更详尽的解释，请参阅  [Contributor License Agreement FAQ](https://www.djangoproject.com/foundation/cla/faq/)”。

## 方针

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

- **选择一个您关心的，您熟悉的或您想了解的主题区**

  你不必已是你想要工作的领域的专家; 您将通过对代码的持续贡献成为专家。
- **Analyze tickets' context and history**

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

  在小问题上得到反馈比在大问题上得到反馈要容易得多。请参阅 [easy pickings](https://code.djangoproject.com/query?status=!closed&easy=1)。
- **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**](https://peps.python.org/pep-0008/),  并且必须有文档和测试" 时，我们是认真的。如果补丁没有文档和测试，最好有一个好的理由。像“我找不到这个特性的任何现有测试”这样的论据不会有多少说服力——虽然这可能是真的，但这意味着你要为这个特性编写最初的测试，而不是完全通过编写测试获得通过。

## FAQ

1. **我关心的这份工单已经被忽略了好几天/几周/几个月了！我该怎么做才能让它接受？**

   首先，这不是私人的。有时候，Django完全是由志愿者开发出来的（除了Django团队成员），只是有些时候没有。最好的办法是给 [django-developers](/zh-hans/3.1/internals/mailing-lists/#django-developers-mailing-list) 邮件列表发送一个温和的提醒，要求对工单进行复查，或者在 `#django-dev` IRC频道中提出。
2. **I'm sure my ticket is absolutely 100% perfect, can I mark it as RFC
   myself?**

   简单回答：不，在工单上再找一个人总是更好的。如果你找的那个人有问题，请看上面的问题1。