--- a/doc/v2_planning/code_review.txt	Tue Dec 14 12:32:42 2010 -0500
+++ b/doc/v2_planning/code_review.txt	Tue Dec 14 12:53:58 2010 -0500
@@ -10,13 +10,66 @@
 TODO
 ----
 
-- Install Review Board and try it
-    - test review of merge
-    - how work with branch
-- Write our proposed politic
+- Test the 2 proposed workflow (review board and github)
+
+Reason for the code review
+--------------------------
+
+- We want at least 2 people to read all code. That mean we need a reviewer
+- This help to find better solution to problem
+- This help to train people on our tools and framework
+- This give better code and less bug in the end.
+    - Everybode make mistake...
+
+Proposed Politic
+----------------
+
+Their is 2 proposal that we want to test:
 
-Some system that we should check:
----------------------------------
+- GitHub fork/merge/merge request for new Pylearn
+    - When someone ask for a merge request, someone else make the review.
+- Review Board post-commit for Theano
+    - For each commit message, if the author don't want this commit to be reviewed, tell it in the message
+        - Usefull for experimental repository, not Theano
+        - Usefull for Official repo when we commit something that is disabled by default and we want to split it in many commits or start using it event if not fully tested.
+        - Reviewer should check that it is not enabled by default and when enabled it print a warning(once per job execution)
+    - We check all commit to Theano and Jobman.(Official tools)
+    - If the official review is not the right person for the task(gpu code,...)
+      He have the responsability to find the right persone (ask people in the lab, mailing-list, ...)
+    - The official reviewer should do:
+         - Review all code(see the check list) and ask expert when needed.
+         - Should check the check list again all review.
+         - We choose the reviewer in the theano user of the lab with commit right.
+         - We make a list of expert by domain of problem.(gpu, optimization, algo,...)
+    - For the test, the official reviewer work for one day.
+    - Later when we finish the test, maybe we will want to make that longer(1 week?)
+         - If some body break the build bot, it is him the reviewer for the next week/days
+         - Maximum of one week by month.
+         - If their is big week or during rush that include every body of the lab, we can change more frequently.
+         - If a commit have problem, it is the original reviewer that should make the follow up.
+
+We should never be the official reviewer of our own code. When this happen, ask someone else to do it.
+
+Check list for review
+---------------------
+
+- Is their tests and do they test all case?
+    - Do test cover all case?
+- Is their documentation in the code file?
+    - Do this need doc in the html(public) documentation?
+- Is the addition well integrated into our framework
+- Is the code well placed in the right files and right place in them?
+- Try to don't duplicate code
+- Is the code clear/comprehensible
+- Are the comment describing what is being done?
+- Answer question by de commiter, this can also serve to train people
+- Check for typo
+- No debug code(print, breakpoint,...)
+- If commit message tell to don't review, check that the code is disabled by default and that when enabled print a warning.
+- Check for conformence to our coding guideline
+
+Some system that we checked
+---------------------------
 
 - `Review Board <http://www.reviewboard.org>`_
     - Interesting, but some questions remain (how well it integrates with hg,
@@ -24,6 +77,8 @@
     - Some advantages over Google code (comment on multi-line chunks, list of
       unreviewed commits, more esthetics, handle many repo, keep assemble easily)
     - Fred will install it so we can test it more thoroughly
+- `GitHub pull request <https://github.com/blog/712-pull-requests-2-0>`_
+    - pre-commit review
 
 - `Google Code <http://code.google.com/p/support/wiki/CodeReviews>`_
     - Test bench with a clone of Theano at
@@ -103,44 +158,3 @@
 
 We seam to do Over-the-shoulder, email and variant of pair programming from time to time. Some people read rapidly the commit of Theano and Pylearn.
 
-Reason for the code review
---------------------------
-
-- We want at least 2 people to read all code. That mean we need a reviewer
-- This help to find better solution to problem
-- This help to train people on our tools and framework.
-
-Check list for review
----------------------
-
-- Is their tests and do they test all case?
-- Is their documentation in the file?
-    - Do this need doc in the html doc?
-- Is the addition well integrated into our framework
-- Is the code well placed in the right files and right place in them?
-- Try to don't duplicate code
-- Is the code clear/comprehensible
-- Are the comment describing what is being done?
-- Answer question by de commiter, this can also serve to train people
-- Check for typo
-- No debug code(print, breakpoint,...)
-- If commit message tell to don't review, check that the code is disabled by default and that when enabled print a warning.
-
-Proposed Politic
-----------------
-
-- For each commit message, if the author don't want this commit to be reviewed, tell it in the message
-   - Usefull for experimental repository, not Theano
-   - Usefull for Official repo when we commit something that is disabled by default and we want to split in many commits or start using event if not fully tested.
-   - Reviewer should check that the check is not enabled by default and when enabled should print a warning.
-- We check all commit to Theano, Pylearn and Jobman.(Official tools)
-- We check experimental repos when asked.
-- One official reviewer per week.
-    - He review all code and ask expert when needed.
-    - Should check the check list again all review.
-    - We choose the reviewer in the theano user of the lab with commit right.
-    - On fait une list d'expert par demain de problem(gpu, optimization, algo,...)
-    - If some body break the build bot, it is him the reviewer for the next week
-    - Maximum of one week by mount.
-    - If their is big week or during rush that include every body of the lab, we can change more frequently.
-    - If a commit have problem, it is the original reviewer that should make the follow up.