---
title: "新しいコントリビューターへのアドバイス"
version: 4.2
locale: ja
source: https://docs.djangoproject.com/ja/4.2/internals/contributing/new-contributors/
canonical: https://djangodocs.dev/ja/4.2/internals/contributing/new-contributors/
---
# 新しいコントリビューターへのアドバイス

新しいコントリビューターで、何をするべきかわかりませんか？ 助けたいと思っているのにどこから手を付ければいいのかわかりませんか？ このセクションはあなたのためにあります。

> **立ち上げる！**
>
> Django へのコントリビューションが初めての場合、[Django への初めてのパッチを書く](/ja/4.2/intro/contributing/) チュートリアルがツールとワークフローへの導入の助けとなるでしょう。

このページでは、Django へのコントリビューション方法とそのためのアプローチについて、より一般的なアドバイスをします。

パッチを書く方法の細かい参照文献を探しているなら [Writing code](/ja/4.2/internals/contributing/writing-code/) ドキュメントを参照してください。

## 最初のステップ

Django の開発プロセスを知るには、以下のステップから始めてください。

- **チケットをトリアージする**

  If an [unreviewed ticket](https://code.djangoproject.com/query?status=!closed&stage=Unreviewed) reports a bug, try and reproduce it. If you
  can reproduce it and it seems valid, make a note that you confirmed the bug
  and accept the ticket. Make sure the ticket is filed under the correct
  component area. Consider writing a patch that adds a test for the bug's
  behavior, even if you don't fix the bug itself. See more at
  [How can I help with triaging?](/ja/4.2/internals/contributing/triaging-tickets/#how-can-i-help-with-triaging)
- **アクセプトされたチケットを探してパッチをレビューすることで、コードベースとプロセスに慣れる**

  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](/ja/4.2/internals/contributing/writing-code/unit-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](/ja/4.2/internals/contributing/writing-code/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
  [Writing documentation](/ja/4.2/internals/contributing/writing-documentation/).

  > **Note**
  >
  > The [reports page](https://code.djangoproject.com/wiki/Reports) contains links to many useful Trac queries, including
  > several that are useful for triaging tickets and reviewing patches as
  > suggested above.
- **Contributor License Agreement に署名する**

  The code that you write belongs to you or your employer. If your
  contribution is more than one or two lines of code, you need to sign the
  [CLA](https://www.djangoproject.com/foundation/cla/). See the [Contributor License Agreement FAQ](https://www.djangoproject.com/foundation/cla/faq/) for a more thorough
  explanation.

## ガイドライン

As a newcomer on a large project, it's easy to experience frustration. Here's
some advice to make your work on Django more useful and rewarding.

- **興味がある、馴染みがある、学んでみたい主題エリアを選ぶ**

  You don't already have to be an expert on the area you want to work on; you
  become an expert through your ongoing contributions to the code.
- **チケットの文脈と歴史を分析する**

  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.
- **小さく始める**

  It's easier to get feedback on a little issue than on a big one. See the
  [easy pickings](https://code.djangoproject.com/query?status=!closed&easy=1).
- **大きなタスクに取り組む場合、初めに自分のアイデアが支持されるかを確認する**

  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.
- **勇気を出して！ フィードバックを残そう！**

  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.
- **フィードバックを待ち、受け取ったフィードバックに返事を書く**

  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.
- **厳格になる**

  When we say "[**PEP 8**](https://peps.python.org/pep-0008/), 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.
- **忍耐強く**

  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](/ja/4.2/faq/contributing/#new-contributors-faq) for ideas here.