新しい寄稿者へのアドバイス—Djangoドキュメント
新しい寄稿者へのアドバイス
新しい寄稿者で、どうしたらよいかわからない場合は、 手伝いたいのですが、始め方がわかりませんか？ これはあなたのためのセクションです。
このページには、Djangoに貢献する方法と、それにアプローチする方法に関するより一般的なアドバイスが含まれています。
コードの貢献の詳細に関するリファレンスを探している場合は、コードの記述[X104X]のドキュメントを参照してください。
最初のステップ
これらの手順から始めて、Djangoの開発プロセスを見つけてください。
トリアージチケット
未レビューチケットがバグを報告した場合は、それを再現してみてください。 再現可能で有効と思われる場合は、バグを確認したことをメモし、チケットを受け入れてください。 チケットが正しいコンポーネント領域の下に提出されていることを確認してください。 バグ自体を修正しなくても、バグの動作のテストを追加するパッチを作成することを検討してください。 詳細については、トリアージを支援するにはどうすればよいですか？
受け入れられたチケットを探し、パッチを確認して、コードベースとプロセスに精通します。
パッチにドキュメントやテストが必要な場合は、適切なフラグをマークしてください。 パッチによって行われる変更に目を通し、古いがまだサポートされているバージョンのPythonと互換性のない構文に注意してください。 テストを実行し、合格することを確認します。 可能で関連性がある場合は、SQLite以外のデータベースで試してみてください。 コメントやフィードバックを残してください！
古いパッチを最新の状態に保つ
多くの場合、コードベースは、パッチが送信されてからレビューされるまでの間に変更されます。 それでもきれいに適用され、期待どおりに機能することを確認してください。 パッチの更新は便利で重要です。 パッチの送信の詳細を参照してください。
いくつかのドキュメントを書く
Djangoのドキュメントは素晴らしいですが、いつでも改善できます。 タイプミスを見つけましたか？ 何かを明確にすべきだと思いますか？ 先に進んで、ドキュメントパッチを提案してください！ ドキュメントの作成に関するガイドも参照してください。
ノート
レポートページには、チケットの優先順位付けや上記のパッチの確認に役立ついくつかのクエリを含む、多くの便利なTracクエリへのリンクが含まれています。
貢献者ライセンス契約に署名する
あなたが書くコードはあなたまたはあなたの雇用主のものです。 投稿が1行または2行を超えるコードの場合は、 CLA に署名する必要があります。 詳細な説明については、寄稿者ライセンス契約に関するFAQ を参照してください。
ガイドライン
大規模なプロジェクトの新参者として、フラストレーションを感じるのは簡単です。 Djangoでの作業をより便利でやりがいのあるものにするためのアドバイスをいくつか紹介します。
あなたが気にかけている、あなたが精通している、またはあなたが学びたい主題分野を選んでください
作業したい分野の専門家である必要はありません。 あなたはコードへの継続的な貢献を通じて専門家になります。
チケットのコンテキストと履歴を分析する
Tracは絶対的なものではありません。 文脈は言葉と同じくらい重要です。 Tracを読むときは、誰が言ったのか、いつ言われたのかを考慮する必要があります。 2年前のアイデアのサポートは、必ずしもそのアイデアが引き続きサポートされることを意味するわけではありません。 また、誰がを話していないかにも注意を払う必要があります。たとえば、経験豊富な寄稿者が最近ディスカッションに参加していない場合、チケットにはDjangoに入るのに必要なサポートがない可能性があります。
小さく始める
大きな問題よりも小さな問題の方がフィードバックを得る方が簡単です。 簡単なピッキングを参照してください。
大きなタスクに取り組む場合は、最初にアイデアがサポートされていることを確認してください
これは、問題を修正する前に他の誰かにバグが本物であることを確認してもらい、実装する前に提案された機能についてコンセンサスがあることを確認することを意味します。
大胆になります！ フィードバックを残す！
「このチケットは正しい」または「このパッチは作業が必要です」とあなたの意見を世に出すのは恐ろしいこともありますが、それがプロジェクトを前進させる唯一の方法です。 幅広いDjangoコミュニティの貢献は、最終的には誰よりもはるかに大きな影響を及ぼします。 あなたなしではそれはできません！
チェックインの準備ができているものをマークするときの注意の側のエラー
チケットの準備ができているかどうか本当にわからない場合は、そのようにマークしないでください。 代わりにコメントを残して、他の人にあなたの考えを知らせてください。 ほぼ確実であるが完全に確実ではない場合は、IRCに問い合わせて、他の誰かがあなたの疑いを確認できるかどうかを確認することもできます。
フィードバックを待ち、受け取ったフィードバックに返信します
1つまたは2つのチケットに焦点を合わせ、最初から最後までそれらを確認し、繰り返します。 たくさんのチケットを取り、途中でいくつかを落とすというショットガンのアプローチは、結局は良いことよりも害を及ぼすことになります。
厳しくする
「 PEP8 であり、ドキュメントとテストが必要です」とは、それを意味します。 パッチにドキュメントとテストがない場合は、正当な理由があります。 「この機能の既存のテストが見つかりませんでした」などの議論はそれほど重要ではありません。それは本当かもしれませんが、それはあなたがその機能の最初のテストを書くという非常に重要な仕事をしていることを意味します。テストを書くことから完全に合格を得る。
我慢して
チケットやパッチをすばやく確認するのは必ずしも簡単ではありません。 これは個人的なことではありません。 通過するチケットとプルリクエストはたくさんあります。
パッチを最新の状態に保つことが重要です。 Tracでチケットを確認し、すべてのレビューコメントに対処したら、テストが必要、ドキュメントが必要、パッチの改善が必要フラグがオフになっていることを確認します。
Djangoのリリースサイクルは8か月であるため、パッチを確認するための十分な時間があります。
最後に、タイミングの良いリマインダーが役立ちます。 ここでのアイデアについては、寄稿コードFAQ を参照してください。
