プルリクエストのレビューを提供すること¶

経験レベルに関わらず、寄稿者からのレビューをいつでも歓迎しております。

なぜ貢献をレビューするのか？¶

提出されるすべての貢献は、コアチームメンバーによるものか初めての貢献者によるものかを問わず、レビューを受ける必要があります。誰もが何かを見落とす可能性があります。レビュープロセスは追加の安全策として設けられています。

レビュープロセスの目的は、コードやドキュメントを含むすべてのコンテンツが可能な限りバグがなく、保守しやすい状態であることを保証することです。この目標達成に貢献できることは、どんなことでも歓迎します。単純な誤字脱字の修正から、API使用時の想定外のエッジケースの発見まで、その範囲は多岐にわたります。テスト体制をより堅牢にする方法の提案や、変更内容全体のアーキテクチャ設計を、保守や拡張が容易になるよう構築する手法の提言なども含まれます。

確認してもいいですか？¶

Yes! You can offer a review on any pull request you see open on BeeWare.

初めて貢献する方は、プルリクエストを見つけたら、たとえそれがコアチームメンバーによって提出されたものであっても、遠慮なくレビューしてください。初心者の方はプロジェクト全体の文脈を把握できていないかもしれませんが、経験レベルに関わらずコードベースが理解しやすい状態を保つよう努めています。コード内で理解できない部分があれば、それはドキュメントの追加（コード内または独立した設計文書として）が必要であることを示している可能性があります。

プルリクエストのレビューへの貢献¶

プルリクエストのレビューを提供すること

BeeWareプロジェクトへのあらゆる貢献は、どなたでもレビューいただけます。始める前に、いくつか重要な注意点をご確認ください。

レビューする前に考えてください¶

レビューを行う前に、よく考えてください。レビュアーとして、送信しようとしている返信が以下の条件を満たしているか検討すべきです：

その通りです。常に正確な提案と情報を提供するよう努めてください。
有益です。提出物の改善方法に関するガイダンスを提供します。このガイダンスでは、問題点や考慮されていないユースケースの原因を明確に特定し、理想的には懸念事項を解決または満たすための具体的な解決策を示す必要があります。
感動的だ。著者に対し、私たちが求めた変更点に取り組みたいと思わせるよう、私たち自身が奮い立たせる責任がある。
必要不可欠です。投稿内容はすべて著者が読むものと想定されています。必要最小限の投稿に留め、著者の時間と労力を尊重しなければなりません。
親切であること。同じフィードバックを伝える方法は複数あります。私たちは言葉を選ぶ際に、親切で、支えとなり、建設的な姿勢を保つよう心がける必要があります。

効果的なレビューを提供しながら、同時に「考える」ことは十分に可能です。前述の概念は、プルリクエスト（PR）で見つけた問題を指摘することを妨げるものではありません。改善が必要な領域を認識しなければ、貢献者は自身の貢献を向上させる機会を得られません。重要なのは、このフィードバックをどのように提示しているかを常に意識することです。レビューは非人格的に行うよう心がけましょう。「あなたは間違いを犯しました」ではなく、「このコードは改善の余地があります」と伝えられます。作者ではなくコードそのものをレビューするのです。

改善が必要な点を指摘するだけでなく、肯定的なフィードバックを提供することも重要です。例えば、変更が特に有益であった場合、特に巧妙な手法が使われている場合、あるいは未知のAPIを紹介された場合などは、作者にその旨を伝えましょう。他の指摘事項が全て解決すべき課題である状況下で、誰かが正しく、あるいは優れたことを成し遂げた点を指摘する効果を決して過小評価してはいけません。

GitHubのレビュー提案¶

GitHubのレビューインターフェースには変更提案機能があり、既存の内容に代わる具体的な変更案を提供できます。ただし、これらの提案された変更は、受け入れられてコミットされるまでは、コミット前の検証やリンティングチェックの対象外となる点に留意してください。したがって、この機能は小規模な変更に限定して使用すべきです。提案する変更が大きければ大きいほど、問題を引き起こす可能性が高まるためです。