Gerrit/Code review/Getting reviews

From MediaWiki.org
Jump to: navigation, search
To learn about reviewing code from others check the tutorial and the Code review guide.

How to get your code changes reviewed faster and make it more likely to get accepted?

Prerequisites[edit]

Now you plan to create a patch to upload to Gerrit to get your code reviewed and merged (included in the code base).

Your patch[edit]

Check beforehand if it is in scope[edit]

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[1]. This will save you time and potential disappointment.

Test your changes[edit]

Test your changes in your development environment to make sure there are no compilation errors or test failures. If you have not tested your patch for some reason, explicitly say so in a comment in Gerrit. Consider going through the Pre-commit checklist.

Avoid providing incomplete fixes or introducing new bugs. If you know that your patch needs more work, explicitly say so in Gerrit by reviewing it as "-2" or adding a "[WIP]" prefix to the commit message.

Write small commits[edit]

Small, independent, complete patches are more likely to be accepted.[2][3] The more files there are to review in your patch, the more time and effort a review will take[4] and the more likely several a larger number of review iterations will be needed[5].

If your commits are going to be touching separate files and there's not a lot of dependency between them, it's probably best to keep them as smaller discrete commits.

Furthermore, make sure to not include unnecessary changes in your patch[1] (e.g. fixing the coding style).

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

Write a meaningful commit message[edit]

Commit message should describe what and why. What was the problem? How does the fix resolve it? How to test that it actually works? See Gerrit/Commit message guidelines for more.

Also, make sure to proofread and use proper spelling and punctuation in your commit message.

Provide documentation[edit]

If a feature in your patch is going to be visible to end users or administrators, make sure to update or create related documentation[1]. See Development policy#Documentation policy for more information.

Don't mix rebases with changes[edit]

When rebasing, only rebase. 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. When you're making a real change, leave a Gerrit comment explaining your change, and revise your commit summary to make sure it's still accurate.

Your activity[edit]

Respond to test failures and feedback[edit]

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.

(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.")

Sometimes you'll receive reviews which you'll perceive as irrelevant, for instance merely cosmetic. Do not ignore such reviews but amend your patch to satisfy trivial requests: You may disagree, but discussing costs time and is more expensive than conceding a point.

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

Code Review Office Hours[edit]

There are office review hours held twice weekly on IRC which you can attend to get feedback on your code. A benefit of this is that you usually get comments on your change and answers to questions you have regarding these comments without any delay in contrast to comments at gerrit. Usually a few developers with +2 are around and will merge your patch if they're regarding it good enough. Scheduled time and other details can be found at Code Review Office Hours.

Add reviewers[edit]

The choice of reviewers plays an important role on reviewing time. More active reviewers provide faster responses.[5]

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 Gerrit/Navigation#System messages 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[edit]

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.

Dealing with possible obstacles[edit]

No timely feedback[edit]

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 git log 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 #wikimedia-devconnect IRC channel or consider attending one of the weekly Code Review Office Hours.

Further reasons for rework or rejection[edit]

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 (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.[1]

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.[1]

See also[edit]

References[edit]

  1. 1.0 1.1 1.2 1.3 1.4 Yida Tao; Donggyun Han; Sunghun Kim, "Writing Acceptable Patches: An Empirical Study of Open Source Project Patches," in Software Maintenance and Evolution (ICSME), 2014 IEEE International Conference on , vol., no., pp.271-280, Sept. 29 2014-Oct. 3 2014
  2. Peter C. Rigby, Daniel M. German, and Margaret-Anne Storey. 2008. Open source software peer review practices: a case study of the apache server. In Proceedings of the 30th international conference on Software engineering (ICSE '08). ACM, New York, NY, USA, 541-550.
  3. Peter Weißgerber, Daniel Neu, and Stephan Diehl. 2008. Small patches get in!. In Proceedings of the 2008 international working conference on Mining software repositories (MSR '08). ACM, New York, NY, USA, 67-76.
  4. Amiangshu Bosu, Michaela Greiler, and Christian Bird. 2015. Characteristics of useful code reviews: an empirical study at Microsoft. In Proceedings of the 12th Working Conference on Mining Software Repositories (MSR '15). IEEE Press, Piscataway, NJ, USA, 146-156.
  5. 5.0 5.1 5.2 Baysal, O.; Kononenko, O.; Holmes, R.; Godfrey, M.W., "The influence of non-technical factors on code review," in Reverse Engineering (WCRE), 2013 20th Working Conference on , vol., no., pp.122-131, 14-17 Oct. 2013
Coding conventionsManual:Coding conventions
General All languagesManual:Coding conventions#Code structure · Development policyDevelopment policy · Security for developersSecurity for developers · Pre-commit checklistManual:Pre-commit checklist · Performance guidelinesPerformance guidelines(draft) · Style guideDesign/Living style guide · Accessibility guide for developersAccessibility guide for developers(draft)
PHP Code conventionsManual:Coding conventions/PHP · PHPUnit test conventionsManual:PHP unit testing/Writing unit tests#Test_conventions · Security checklist for developersSecurity checklist for developers
JavaScript Code conventionsManual:Coding conventions/JavaScript · Learning JavaScriptLearning JavaScript
CSS Code conventionsManual:Coding conventions/CSS
Database Code conventionsManual:Coding conventions/Database · Database policyDevelopment policy#Database policy
Python Code conventionsManual:Coding conventions/Python
Ruby Code conventionsManual:Coding conventions/Ruby
Selenium/Cucumber Code conventionsManual:Coding conventions/Selenium
Java Code conventionsManual:Coding conventions/Java
API client code Standards for API client librariesAPI:Client code/Gold standard