Gerrit/Code review/Getting reviews

How to get your code reviewed faster

 * 1) Write small commits.
 * It's easier for other people to review small changes that only change one thing. We'd rather see five small commits than one big one.
 * 1) Respond to test failures and feedback.
 * 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.  Or hit the Abandon button to remove your commit from the review queue while you revise it.
 * (To see why automated tests fail, click on the link in the "failed" comment in Gerrit, hover over the failed test's red dot, wait for the popup to show, and then click "console output.")
 * 1) Don't mix rebases with changes.
 * When rebasing, only rebase. That makes it easier to use the "Old Version History" dropdown, which greatly quickens reviews. If non-rebase changes are made inside a rebase changeset, you have to read through a lot more code to find it and it's non-obvious.
 * 1) Add reviewers.
 * Experienced developers should try to help with this. If you notice an unreviewed changeset lingering, then please add a review request or two.  (These are requests – there's no way to assign a review to someone in Gerrit.)  But it's faster if you do it right after committing.  Some tricks:
 * Check the Maintainers list to find who's currently maintaining that part of the code.
 * Click the name of the repository ("Gerrit project"), e.g. operations/debs/squid, and remove "status:open" from the search box to find other changesets in that repository. The people who write and review those changesets would be good candidates to add as reviewers.
 * Search through other commit summaries and changesets. Example: Matmarex and Foxtrott are interested in reviewing frontend changes, so I 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.  Learn more at https://gerrit.wikimedia.org/r/Documentation/user-search.html.
 * 1) Review more.
 * Many eyes make bugs shallow. Read 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, gain reputation, and get people to return the favor by reviewing you in the future.  "How to review code in Gerrit" has the step-by-step explanation.  Example Gerrit search for MediaWiki commits that have not had +1, +2, -1, or -2 reviews yet.
 * 1) Adhere to the coding conventions.
 * When you adhere to the coding conventions, the person reviewing your code can focus on the meaning of your change, rather than be distracted by its superficial qualities. Hewing to the code conventions also shows care, and is therefore more likely to elicit to constructive reviews.