Gerrit/Code review/Getting reviews/ja


 * To learn about reviewing code from others check the tutorial and the Code review guide.

コードの変更をより速くレビューしてもらい、受理される可能性を高めるにはどうしたらいいでしょうか?

要件

 * バグを修正したり、新しい機能を追加するために、あなたが変更したコードがあること.
 * You have followed the Coding conventions.
 * You have followed the Pre-commit checklist.
 * You have followed the.
 * You have a to use with Gerrit and successfully set up Git/Gerrit on your machine.

さて、あなたはパッチを作成して Gerrit にアップロードし、コードのレビューとマージ (コード ベースへの取り込み) を受けようと計画しています.



あなたのパッチ


スコープの範囲内かどうか事前に確認
If your proposed code changes do not fix a bug but introduces a new feature instead, speak first to the maintainers to make sure that your idea is in the project scope and that your proposed technical approach is the optimal solution. これを行うことで、時間の節約と潜在的な失望を削減できます.



あなたの変更をテストする
Test your changes in your development environment to make sure there are no compilation errors or test failures. 何らかの理由でパッチをテストしていない場合は、Gerrit のコメントでその旨を明示してください. Consider going through the Pre-commit checklist.

不完全な修正や新たなバグを発生させないようにしましょう. あなたのパッチにもっと作業が必要だとわかっている場合は、Gerrit で「-2」としてレビューするか、コミット メッセージに「[WIP]」 (work in progress: 作業進行中) の接頭辞をつけるなどして、明示的にその旨を伝えてください.



小規模なパッチを書く
小規模で独立していて完全なパッチが、より受け入れられやすいのです. The more files there are to review in your patch, the more time and effort a review will take and the more likely several reviews or a larger number of review iterations will be needed.

コミットが別々のファイル群に変更を加えるものであり、その間にあまり依存関係がない場合は、より小さな個別のコミットとしたほうがいいかもしれません.

さらに、パッチに不必要な変更 (例えば、コーディング スタイルの修正など) を含めないように注意してください.

However, if your commits are going to be touching the same files repeatedly, bundle them up into one large commit (using either  or squashing after the fact).



意味のあるコミット メッセージを書く
コミット メッセージでは内容と理由を説明すべきです. 何が問題点でしたか? それをどのように解決しましたか? 正しく動作することをテストする方法は? See for more.

また、コミット メッセージは必ず校正し、正しい綴りや句読点を使用するようにしましょう.



説明文書を追加
パッチに含まれる機能がエンド ユーザーや管理者の目に見えるようになる場合、関連する説明文書を更新または作成するようにしてください. See Development policy#Documentation policy for more information.



リベースと変更を混同しない
When rebasing, only rebase. リベース以外の変更がリベースの変更セット内で行われた場合、それを見つけるためにさらに多くのコードを読み通さなければならず、明白ではありません. 実際に変更を行う場合は、変更内容を説明する Gerrit コメントを残し、コミットの要約が正確であることを確認して訂正します.



あなたの作業


テストの失敗やフィードバックへの対応
Check your Gerrit settings and make sure you're getting email notifications. If your code fails automated tests, or you got some review already, respond to it in a comment or resubmission.

(自動テストが失敗した理由を見るには、Gerrit の「失敗」コメントのリンクをクリックし、失敗したテストの赤い点にカーソルを合わせ、ポップアップが表示されるまで待ち、「コンソール出力」をクリックします. )

Feedback will usually (but not always) come with a C-2, C-1, C+1, or C+2 flag from Gerrit. You can read more about what these mean (from the reviewer's perspective) at Gerrit/Code review#Complete the review. レビュアーの中には、新人投稿者を安心させるために、明示的な C-1 評価を用いずに改善点を指摘する人もいます. それでも彼らの提案を真摯に受け止めるべきでしょう.

時には、あなたが無関係と認識するようなレビュー、例えば単なる表面的なレビューが届くこともあります. そのようなレビューを無視するのではなく、些細な要望を満たすためにパッチを修正しましょう. あなたは反対するかもしれませんが、議論するには譲歩するよりも時間を消費します.

コード レビューとは、選挙に勝つことではなく、合意形成の問題です. あなたは、ネガティブなフィードバックに対処することが期待されており、ポジティブなレビューをさらに求めて「反対票を投票」(outvote) することはできません. Addressing negative feedback does not always require changes to your patch: sometimes all that is required is a better explanation. However, even in those cases it can be useful to incorporate those explanations into the commit message or comments in the code to better inform future maintainers with the same concerns.

In general: Be patient and grow. More experienced patch writers receive faster responses and also more positive ones.



レビュアーを追加
The choice of reviewers plays an important role on reviewing time. More active reviewers provide faster responses.

Right after you commit, add one or two developers to the changeset as Reviewers. (These are requests – there's no way to assign a review to one specific person in Gerrit.) Experienced developers should help with this: if you notice an unreviewed changeset lingering, then please add reviewers. To find reviewers:


 * Check the main maintainers list, or the maintainers listed in the extension's page, to find who's currently maintaining that part of the code, or is in maintainer training.
 * Click the magnifying glass in the "Project" row of your gerrit patch. Now find other changesets in that repository: the people who write and review those changesets would be good candidates to add as reviewers. Or see who can approve your patch: click "Access" in the top navigation bar, click the link(s) in "Owner" rows, see the list of names.
 * To find out who added a system message and why, see Special:MyLanguage/Gerrit/Navigation for specific advice.
 * Search through other commit summaries and changesets. Navigate the repository tree to your repository or directory and click "View History" to see who is active in the area, for instance changes in the database of MediaWiki core. Or search on Gerrit: Matma Rex and Foxtrott are interested in reviewing frontend changes, so you can search for "message:css" to find changesets that mention CSS in their commit summaries to add them to. You can use this and regexes to find changes that touch the same components you're touching, to find likely reviewers (search docs).

Review more
Many eyes make bugs shallow. Read the Code review guide and help other authors by praising or criticizing their commits. Comments are nonbinding, won't cause merges or rejections, and have no formal effect on the code review. But you'll learn by reviewing, gain reputation, and get people to return the favor by reviewing your proposed code changes in the future. "How to review code in Gerrit" has the step-by-step explanation.

No timely feedback
Manpower in free and open source software projects is limited, and interests of developers may change. Some code repositories are more active and maintained and you will receive quicker reviews. Other areas have unclear maintainership or are even abandoned and you might have to wait for a long time.

You can check the latest activity in a code repository by looking at the "Recent Commits" list of the repository in Diffusion or via  in your local checkout. To take over an abandoned project and become its maintainer, follow these steps.

If you think that your patch has been gone unnoticed for a longer time, feel free to bring up the problem on the IRC channel.

Further reasons for rework or rejection
Even if you have followed all recommendations, your patch might still require some rework (or in rare cases even get rejected).

Apart from what has been mentioned already, there are more potential reasons for rejection (not all of them are equally decisive), such as a suboptimal solution when there is a more simple or efficient way, performance issues, security issues, improvable naming (e.g. of variables), integration conflicts with existing code, duplication of work, unintended (mis)use of the API, or proposed changes to internal APIs being considered too risky.

Be aware that there is a mismatch of judgement: Patch reviewers often consider test failures, an incomplete fix, introducing new bugs, a suboptimal solution, and inconsistent docs way more decisive for rejecting a patch than patch authors.



関連項目

 * "5 tips to get your code reviewed faster"
 * "Code review meeting notes" (from 2012; relevant parts are now included in the present documentation)