Goal: 
Constructively review a software fix for a bug proposed by a different developer. The proposed changes could be in the form of a patch file or a merge request.
Detailed steps: 
  1. Set up prerequisites: Log in, (optional) Git, (optional) Local development site, and (optional) be ready to use an Online development site from Common Prerequisites for Contributors.
  2. Get into a constructive frame of mind by reviewing the Issue Etiquette page.
  3. Select a project to work on: either Drupal core or a contributed module, theme, or distribution project that you are familiar with.
  4. Find the issues for the project.
  5. Filter the issue list to category Bug report and status Needs review, and select an issue to work on. If you have not reviewed patches before, you might consider selecting an issue that has only a few comments, as these are likely to be less complex than issues with many comments. If you are a good technical writer or editor, and have an interest in improving code documentation, consider reviewing issues in the Drupal core issue list in component documentation (you can filter the issue list by component to find these issues).
  6. Once you've picked an issue, click the issue title to open the issue page.
  7. Read the issue summary. If the issue does not have a complete summary, set the issue status to Needs Work, add the tag "Needs issue summary update", and add a comment saying what's missing (see Creating and updating issues for details on how to update the issue). Alternatively, you can update the issue summary by following the steps in the issue summary task writeup.
  8. If the bug that is being fixed involves changing software behavior, follow the steps in the manual test task writeup to set up an online development site, verify that you can reproduce the problem, and verify that the proposed patch or merge request fixes the problem. If not, you will have set the issue status to Needs Work, and you're done. If it does work, don't save your comment yet, because there are additional review steps.
  9. Find the patch file or merge request:
    • If the issue has a merge request, you'll see a merge request area after the issue summary and before the comments. Click the changes link in the merge request area to view the changes. To add a review note, hover over the changed line of code that you want to add the note to. You'll see a Note button appear on the left side where the line numbers are. Click that button to open a comment form. After finishing your code review, you still need to return to the issue and add a comment to the issue to summarize the review (see below).
    • If the issue doesn't have a merge request, there should be a file with extension .patch listed after the issue summary. To add review notes, you will need to put them in the comment form on the issue. It is very helpful to make a numbered list of your review notes, so that people can respond by number. It is also very helpful to include a few lines of code with each review note, wrapped in <code></endcode> tags, for reference.
  10. Review the patch or merge request, creating a review note for each problem you find. Things to look for in any issue:
    • Do the code changes address the issue the patch is intended to correct?
    • Do the changes stay within scope to address only that issue? (Note: the scope information in that link is somewhat specific to the Drupal core project, but the general ideas apply to most projects.) If unrelated issues are found, there should be separate follow-up issues to address them (if not, you can create those issues).
    • Is the new code well-commented?
    • Are the comments free of typographical errors?
    • Do the code and comment changes meet the Drupal project coding standards?
    • If the patch changed behavior of code or added new behavior, does it include updates to automated tests or new automated tests? (We need to have automated tests in order to ensure that bugs don't come back at a later date.)
    • If the patch includes automated tests, are they both necessary and sufficient?
  11. If there are changes or additions to API documentation and comments, if the issue has a patch rather than a merge request, and you have Git set up, it will be helpful to clone the project code and apply the patch, so that you can review the documentation and comment changes in context. (Merge requests automatically allow you to review changes in context.). Here is a list of things to look for, specifically, in the area of comments and API documentation -- for details see the  standards for API documentation and comments:
    • Is every @param and @return of each function and method documented, with type specifiers? Are class properties documented with @var and a type specifier? Things to look for on type specifiers:
      • Are array type specifiers detailed enough? E.g., "string[]" is more useful than just "array".
      • If the method can return either a string or NULL, then the type specifier should be "@return string|null".
      • If a property is not initialized on object construction, it MUST have a "|null", e.g. "@var array|null"
      • In some cases, the special return value is not NULL, but FALSE. So, this would be "@return array|false".
    • Does every class, method, function, and property have a documentation header including at least a one-line description starting with a third-person verb and ending with a . ?
    • Are the descriptions accurate, concise, and complete?
    • Is the spelling and grammar correct? All comments should be written in complete sentences, ending with .
    • Are @param, @return, @see, and @throws tags in the correct order, with the correct indentation?
    • For // comments, is there a space between the // and the comment?
    • For /** */ comments, does every line start with a properly-indented * and then a space (additional spaces for indentations)?
    • Are all comment lines wrapped at 80-character lines?
  12. After finishing your reviewing and testing, update the issue:
    • If the change was in a merge request, write a comment that summarizes your code review, and note that your review comments are on the merge request yourself.
    • If the change was in a patch, and you didn't already write review notes, add a summary of your review.
    • Make sure your comment notes what you reviewed and tested, and what you were looking for (coding standards, good comments, etc.).
    • Make sure your comment is constructive!
    • If you didn't find any problems and you did a complete review and test, change the issue status to Reviewed and tested by the community.
    • If you didn't find any problems but you didn't review and test everything, leave the issue status at Needs review so that someone else can complete the review and test.
    • If you found one or more problems, even if they are small, change the issue status to Needs work. Make sure to thank the contributor for the work and identify what is done correctly as well as identifying the problems.
  13. When the status is set and you've reviewed your comment to make sure it is both accurate and constructive, click Save to save your issue updates and comment.