对新贡献者的建议

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

基本工具和工作流程

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

快速入门

Start with these steps to discover Django’s development process.

• 分类工单

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

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

  Mark the appropriate flags if a patch needs docs or tests. Look through the changes a patch makes, and keep an eye out for syntax that is incompatible with older but still supported versions of Python. Run the tests and make sure they pass. Where possible and relevant, try them out on a database other than SQLite. Leave comments and feedback!

• 更新旧的的修补程序

  Oftentimes the codebase will change between a patch being submitted and the time it gets reviewed. Make sure it still applies cleanly and functions as expected. Updating a patch is both useful and important! See more on Submitting patches.

• 撰写一些文档

  Django’s documentation is great but it can always be improved. Did you find a typo? Do you think that something should be clarified? Go ahead and suggest a documentation patch! See also the guide on 编写文档.

  注解

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

• 签署贡献者许可协议

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

方针

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

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

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

• Analyze tickets’ context and history

  Trac isn’t an absolute; the context is just as important as the words. When reading Trac, you need to take into account who says things, and when they were said. Support for an idea two years ago doesn’t necessarily mean that the idea will still have support. You also need to pay attention to who hasn’t spoken — for example, if an experienced contributor hasn’t been recently involved in a discussion, then a ticket may not have the support required to get into Django.

• Start small

  It’s easier to get feedback on a little issue than on a big one. See the easy pickings.

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

  This means getting someone else to confirm that a bug is real before you fix the issue, and ensuring that there’s consensus on a proposed feature before you go implementing it.

• Be bold! Leave feedback!

  Sometimes it can be scary to put your opinion out to the world and say “this ticket is correct” or “this patch needs work”, but it’s the only way the project moves forward. The contributions of the broad Django community ultimately have a much greater impact than that of any one person. We can’t do it without you!

• Err on the side of caution when marking things Ready For Check-in

  If you’re really not certain if a ticket is ready, don’t mark it as such. Leave a comment instead, letting others know your thoughts. If you’re mostly certain, but not completely certain, you might also try asking on IRC to see if someone else can confirm your suspicions.

• Wait for feedback, and respond to feedback that you receive

  Focus on one or two tickets, see them through from start to finish, and repeat. The shotgun approach of taking on lots of tickets and letting some fall by the wayside ends up doing more harm than good.

• Be rigorous

  When we say “PEP 8, and must have docs and tests”, we mean it. If a patch doesn’t have docs and tests, there had better be a good reason. Arguments like “I couldn’t find any existing tests of this feature” don’t carry much weight—while it may be true, that means you have the extra-important job of writing the very first tests for that feature, not that you get a pass from writing tests altogether.

FAQ

1. This ticket I care about has been ignored for days/weeks/months! What can I do to get it committed?

   First off, it’s not personal. Django is entirely developed by volunteers (except the Django fellow), and sometimes folks just don’t have time. The best thing to do is to send a gentle reminder to the django-developers mailing list asking for review on the ticket, or to bring it up in the #django-dev IRC channel.

2. I’m sure my ticket is absolutely 100% perfect, can I mark it as RFC myself?

   Short answer: No. It’s always better to get another set of eyes on a ticket. If you’re having trouble getting that second set of eyes, see question 1, above.