Code Correctness - Check that code does what it says, finding bugs early, so that there are no issues further down the development cycle. Reviewers should not recommend changes because of personal preferences, For any Alternatives to code that reviewer suggests are only valid if they improve comprehension or are more efficient, in any other case Author method is given precedence.

Comprehension of the code - Make sure that the code is Readable and is understandable by a wider audience

Code Readability -

GDG Web and App Team Style Guide

Be polite and professional -

1. Ask why instead to assuming something is wrong
2. a Code review is a learning opportunity for both the reviewer and the Author
3. Author should not add or add more modifications to the code after submitting a pr, as that will lead to reviewer needing to review the code again.
4. Author need not accept any changes Reviews says without question, let them know why you don't agree with it. Each side should offer alternatives and keep the debate civil
5. Even if the solution is not perfect is it improves the code base it should be given preference.
6. Reviewer should respond to the review within 24 hours, this does not mean that code is reviewed within 24h but that initial feedback is given within 24h.
7. Other members can comment on the issue and suggest improvements to the code but only approval of the Reviewer is required to proceed

Automate the Process - use tools ESLint to catch basic issues before submitting the code for review

Only focus on issue at hand - it can be tempting to fix multiple issues in a single go but that makes it harder for reviewer to know what changes you have made to the code base.