Add sub-section for review comment labeling in code review section (#…

…1732)

* add sub-section for review comment labeling in code review section

* Update content/en/contribute/code/workflow.md

Co-authored-by: mrjones <[email protected]>

---------

Co-authored-by: mrjones <[email protected]>

content/en/contribute/code/workflow.md

@@ -138,6 +138,29 @@ Once you are confident that the change is complete and ready to be merged:
 
 The author and reviewer should use this [guide to code reviewing](https://google.github.io/eng-practices/review/developer/).
 
+##### Labeling review comments
+
+The reviewer should prefix labels in the review comments wherever possible which clarify the intention of the comment and remove any misunderstanding that might happen. This helps prioritizing the comments that the author need to address.
+
+The following labels taken from [conventional: comments](https://conventionalcomments.org/):
+
+* **praise** - Praises highlight something positive. Try to leave at least one of these comments per review. Do not leave false praise (which can actually be damaging). Do look for something to sincerely praise.
+* **nitpick** - Nitpicks are trivial preference-based requests. These should be non-blocking by nature.
+* **suggestion** - Suggestions propose improvements to the current subject. It’s important to be explicit and clear on what is being suggested and why it is an improvement. Consider using patches and the blocking or non-blocking [decorations](https://conventionalcomments.org/#decorations) to further communicate your intent.
+* **issue** - Issues highlight specific problems with the subject under review. These problems can be user-facing or behind the scenes. It is strongly recommended to pair this comment with a suggestion. If you are not sure if a problem exists or not, consider leaving a question.
+* **todo** - TODO’s are small, trivial, but necessary changes. Distinguishing todo comments from issues: or suggestions: helps direct the reader’s attention to comments requiring more involvement.
+* **question** - Questions are appropriate if you have a potential concern but are not quite sure if it’s relevant or not. Asking the author for clarification or investigation can lead to a quick resolution.
+* **thought** - Thoughts represent an idea that popped up from reviewing. These comments are non-blocking by nature, but they are extremely valuable and can lead to more focused initiatives and mentoring opportunities.
+* **chore** - Chores are simple tasks that must be done before the subject can be “officially” accepted. Usually, these comments reference some common process. Try to leave a link to the process description so that the reader knows how to resolve the chore.
+* **note** - Notes are always non-blocking and simply highlight something the reader should take note of.
+
+
+Sample comments:
+
+![Issue comment](issue-comment.png)
+
+![Suggestion comment](suggestion-comment.png)
+
 #### Suggestions
 
 When doing a code review aim to be extremely clear. This helps things move quickly and avoids lost time in misunderstandings. One especially useful GitHub feature for doing this is suggesting a change. Consider the following example code: