Swarm 2014.1: User Guide

Review workflow

There are many possible code review workflows. The section describes two typical scenarios for a code review that Swarm can handle.

Another developer reviews your code

  1. You request a code review with a shelved change.

  2. Another developer, Bill, sees the email notification from Swarm, clicks the review link in the email, and begins looking at the diffs in the files belonging to the review. Curious about an implementation detail, Bill clicks the line he's curious about and adds his query in a Swarm comment.

  3. You receive an email notification regarding Bill's query. His query prompts you to clarify the code, say by renaming some variables and adding some better descriptive text in the surrounding code comments. You then update the review with your changes.

  4. Bill sees the email notification that you have updated the review. He checks out the change, likes what he sees, and marks the review Approved.

  5. You see the email notification that Bill has approved your review, so you commit your code.

You review another developer's code

  1. Another developer, Charlie, requests a code review with a shelved change.

  2. You receive an email notification from Swarm, click the review link in the email, and begin looking at the diffs in the files belong to the review. You don't like what you see, as Charlie has tried to fix a bug using a technique you have already tried previously and know to be incorrect. You add comments to the code that needs attention, and mark the review Needs Revision.

  3. Charlie receives an email notification regarding your review, but disagrees with you, and adds his own comments justifying his implementation.

  4. You receive an email notification regarding Charlie's comment. The technique is somewhat complicated, so rather than attempt to describe how it is incorrect, you unshelve the review's code to your own workspace, change Charlie's code, and shelve your changes. Swarm updates the review with your new code.

  5. Charlie receives an email notification regarding your updates to the review. He's still unconvinced, but he unshelves your changes to try them in his local workspace. He finds that your implementation works better, but sees a couple of areas where there could be improvements. He reshelves his latest work to update the review.

  6. You receive an email notification regarding Charlie's updates, check out his changes, and realize that Charlie's work is now moot because the customer has revised his plans. You add a comment to the review reporting that fact, and mark the review as rejected.

0 matching pages