Add some efficiency steps for code review

- For the auther, it's more efficient to assign the MR back rather than
mentioning only and hoping that the reviewer will notice.
- For the reviewer, use "Nit:" prefix so that authors do not think
something is a blocking comment and un-necessary waste cyles addressing
it.
- Also add kindness for everyone :)

doc/development/code_review.md

@@ -185,6 +185,7 @@ without duly verifying them.
 
 ### Everyone
 
+- Be kind.
 - Accept that many programming decisions are opinions. Discuss tradeoffs, which
   you prefer, and reach a resolution quickly.
 - Ask questions; don't make demands. ("What do you think about naming this
@@ -231,6 +232,9 @@ first time.
 - Push commits based on earlier rounds of feedback as isolated commits to the
   branch. Do not squash until the branch is ready to merge. Reviewers should be
   able to read individual updates based on their earlier feedback.
+- Assign the merge request back to the reviewer once you are ready for another round of
+  review. If you do not have the ability to assign merge requests, `@`
+  mention the reviewer instead.
 
 ### Assigning a merge request for a review
 
@@ -290,6 +294,9 @@ experience, refactors the existing code). Then:
 - Seek to understand the author's perspective.
 - If you don't understand a piece of code, _say so_. There's a good chance
   someone else would be confused by it as well.
+- If you have an improvement you wish to suggest based on personal
+  preference, do prefix your comment with "Nit:" to let the author know
+  it is not a mandatory improvement.
 - After a round of line notes, it can be helpful to post a summary note such as
   "LGTM :thumbsup:", or "Just a couple things to address."
 - Assign the merge request to the author if changes are required following your