新しいコントリビューターで、何をするべきかわかりませんか？ 助けたいと思っているのにどこから手を付ければいいのかわかりませんか？ このセクションはあなたのためにあります。
\n\nこのページでは、Django へのコントリビューション方法とそのためのアプローチについて、より一般的なアドバイスをします。
\nパッチを書く方法の細かい参照文献を探しているなら Writing code ドキュメントを参照してください。
\nDjango の開発プロセスを知るには、以下のステップから始めてください。
\nチケットをトリアージする
\nもし unreviewed ticket がバグを報告したら、それを再現してみてください。再現でき、それが有効であると思われる場合、バグを確認したことをメモし、チケットを受理してください。チケットが正しいコンポーネントの領域に提出されていることを確認してください。バグ自体を修正しなくても、バグの動作のテストを追加するパッチを書くことを検討してください。詳しくは トリアージを助けるにはどうすればいいですか？ を参照してください。
\nアクセプトされたチケットを探してパッチをレビューすることで、コードベースとプロセスに慣れる
\nパッチがドキュメントやテストを必要とする場合は、適切なフラグをマークしてください。パッチが行う変更を精査し、まだサポートされている古いバージョンのPythonと互換性のない構文に注意してください。 テストを実行し 、それらが合格することを確認してください。関連する場合は、可能ならSQLite以外のデータベースで試してみてください。コメントやフィードバックを残してください！
\n古いパッチを最新の状態に保つ
\nパッチが提出されてからレビューされるまでの間にコードベースが変更されることはよくあります。パッチがきれいに適用され、期待通りに機能することを確認してください。パッチの更新は有用かつ重要です！詳しくは Submitting patches を参照してください。
\nドキュメントを書く
\nDjango のドキュメントは素晴らしいですが、常に改善できます。誤字を見つけましたか？何かを明確にすべきだと思いますか？ドキュメンテーションのパッチを提案してください！ ドキュメントを書く のガイドも参照してください。
\n\nContributor License Agreement に署名する
\nあなたが書いたコードは、あなたかあなたの雇用主のものです。あなたの貢献が1、2行以上のコードである場合、 CLA に署名する必要があります。より詳しい説明は Contributor License Agreement FAQ を参照してください。
\n大規模なプロジェクトでの新参者は、フラストレーションを経験しがちです。ここでは、Django での作業をより便利でやりがいのあるものにするためのアドバイスをいくつか紹介します。
\n興味がある、馴染みがある、学んでみたい主題エリアを選ぶ
\nあなたが取り組みたい分野の専門家である必要はなく、コードへの継続的な貢献を通じて専門家になるのです。
\nチケットの文脈と歴史を分析する
\nTracは絶対的なものではありません。文脈は言葉と同じくらい重要です。Trac を読むときは、誰がいつ言ったかを考慮する必要があります。2年前にあるアイデアが支持されたからといって、そのアイデアがまだ支持されるとは限りません。また、誰が*発言していないか*にも注意を払う必要があります。例えば、経験豊富なコントリビューターが最近議論に関わっていない場合、チケットにはDjangoに取り入れられるために必要なサポートが不足している可能性があります。
\n小さく始める
\n大きな問題よりも小さな問題の方がフィードバックを得やすいものです。 easy pickings をチェックしてみてください。
\n大きなタスクに取り組む場合、初めに自分のアイデアが支持されるかを確認する
\nつまり、問題を修正する前にバグが本物であることを他の誰かに確認してもらうことや、実装する前に提案された機能についてコンセンサスが得られていることを確認することです。
\n勇気を出して！ フィードバックを残そう！
\n「このチケットは正しい」とか、「このパッチには作業が必要だ」とか、自分の意見を世界に発信するのは、時には怖いことかもしれませんが、プロジェクトが前進するた めの唯一の方法です。幅広い Django コミュニティの貢献は、最終的には一個人の貢献よりもずっと大きな影響力を持ちます。私たちは あなた なしではできません！
\nErr on the side of caution when marking things Ready For Check-in
\nチケットが ready かどうか確信が持てない場合は、そのようにマークしないでください。代わりにコメントを残し、他の人にあなたの考えを伝えてください。 ほとんど確信があるけれども完全には確信が持てない場合、IRC で尋ねてみて、他の誰かがあなたの疑念を確かめることができるかもしれません。
\nフィードバックを待ち、受け取ったフィードバックに返事を書く
\n1つか2つのチケットに集中し、最初から最後まで見届け、それを繰り返します。たくさんのチケットを引き受け、いくつかを道端に放置するというショットガンアプローチは、結局、良いことよりも悪いことの方が多いのです。
\n厳格になる
\n私たちが「 PEP 8 に準拠し、ドキュメントとテストが必要だ」と言うとき、それは本気です。パッチにドキュメントやテストがない場合、それには十分な理由があるべきです。「この機能の既存のテストが見つからない」といった理由はあまり説得力がありません。それが事実であったとしても、それはあなたにとってその機能の最初のテストを書くという非常に重要な仕事があることを意味し、テストを書く必要が全くないわけではありません。
\n忍耐強く
\nあなたのチケットやパッチが迅速にレビューされることは、必ずしも容易ではありません。これは個人的なことではありません。たくさんのチケットやプルリクエストがあります。
\nパッチを最新の状態に保つことは重要です。Trac 上でチケットをレビューし、すべてのレビューコメントに対応したら、 Needs tests, Needs documentation, Patch needs improvement フラグのチェックが外れていることを確認してください。
\nDjango のリリースサイクルは 8 ヶ月なので、あなたのパッチがレビューされるのに十分な時間があることを覚えておいてください。
\n最後に、タイミングよくリマインダを送ることも有効です。ここでは contributing code FAQ を参照してください。
\n