Difference between revisions of "Your first review on Zaqar"

Revision as of 06:23, 11 May 2014

Reviewing ang being reviewed

The review stage is a very important part in the development process. There are many reasons to say this:

Getting other developers feedback minimizes the risk of adding regressions to the code base and ensures the quality of the code being merged.
It helps to build community. Everyone appreciate when their code is reviewed, and of course they will review your code when they have their chance.
It also helps developers to improve, since they are always learning from other's points of view.
Its a great practice to get familiar with the code.

Everyone is encouraged to review code! It's not necessary that you know every detail of the code base, you only have to understand what the code related to the fix does.

Checklist

Anyone who is signed in to review.openstack.org can review a patch.
If you already submitted a patch, take a moment to think about the reviews you received. Which were the most useful comments? Consider the feedback that helped you the most in the past and try to do the same for the fix you are reviewing. Helpful review comments will be appreciated by the developer that is submitting the fix.
No idea on how to start? Take a moment to check different reviews for patches in review.openstack.org. Don't forget about inline comments!
Code location feedback. Do you think that some code should be better located in another place within the file, or maybe in another file? If so, suggest it the review comment and qualify with -1 if you think that it's that important.
Code style feedback. Remember about DRY, YAGNI and KISS.

@@ Line 1: / Line 1: @@
+=== Reviewing ang being reviewed ===
-===Resources===
+The review stage is a very important part in the development process. There are many reasons to say this:
-The [https://wiki.openstack.org/wiki/Gerrit_Workflow Gerrit Workflow] page should be your main resource for how to submit a patch. It covers creating the necessary accounts and signing the necessary agreements required for you to submit your patch. It also covers how you should set up your git environment and what your commit messages should look like.
-===Agreements and Accounts===
+* Getting other developers feedback minimizes the risk of adding regressions to the code base and ensures the quality of the code being merged.
-Folllow the [https://wiki.openstack.org/wiki/Gerrit_Workflow#Account_Setup Account Setup] instructions to get all your accounts in order. You will need a launchpad and and openstack account.
+* It helps to build community. Everyone appreciate when their code is reviewed, and of course they will review your code when they have their chance.
+* It also helps developers to improve, since they are always learning from other's points of view.
+* Its a great practice to get familiar with the code.
-===Branches and Commits===
+Everyone is encouraged to review code! It's not necessary that you know every detail of the code base, you only have to understand what the code related to the fix does.
-The [https://wiki.openstack.org/wiki/Gerrit_Workflow#Project_Setup Gerrit Workflow] page contains all  you need to know about setting up your repository for Gerrit. Follow the instructions carefully so you don't miss anything.
-===Git Review===
+=== Checklist ===
-Once you have all your changes and commits looking nice and pretty, you are ready to submit your patch. Follow [https://wiki.openstack.org/wiki/Gerrit_Workflow#Committing_Changes these instructions] to submit your code for review.
+* Anyone who is signed in to review.openstack.org can review a patch.
+* If you already submitted a patch, take a moment to think about the reviews you received. Which were the most useful comments? Consider the feedback that helped you the most in the past and try to do the same for the fix you are reviewing. Helpful review comments will be appreciated by the developer that is submitting the fix.
+* No idea on how to start? Take a moment to check different reviews for patches in review.openstack.org. Don't forget about inline comments!
+* Code location feedback. Do you think that some code should be better located in another place within the file, or maybe in another file? If so, suggest it the review comment and qualify with -1 if you think that it's that important.
+* Code style feedback. Remember about DRY, YAGNI and KISS.