--- a/doc/v2_planning/code_review.txt	Mon Dec 20 18:08:48 2010 -0500
+++ b/doc/v2_planning/code_review.txt	Mon Dec 20 18:09:11 2010 -0500
@@ -10,13 +10,91 @@
 TODO
 ----
 
-- Install Review Board and try it
-    - test review of merge
-    - how work with branch
-- Write our proposed politic
+- Test the 2 proposed workflows (review board and github)
+
+Reasons for code review
+-----------------------
+
+- We want at least 2 people to read all code. That means we need a reviewer.
+- This helps to find better solutions to problems.
+- This helps to train people on our tools and framework.
+- This gives better code and less bugs in the end (everybody makes mistakes).
+
+Proposed Policy
+---------------
+
+There are 2 proposals we want to test:
+
+- GitHub fork/merge/pull request for new Pylearn
+    - When someone asks for a pull request, someone else does the review.
+    - Everyone should work within their own Pylearn fork, and submit pull
+      requests to merge their code into the master Pylearn repository.
+- Review Board post-commit for Theano
+    - For each commit message, if the author does not want this commit to be reviewed, say it in the message
+        - Useful 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 even if not fully tested.
+        - Reviewer should still check that it is not enabled by default and when enabled it prints a warning (once per job execution).
+    - We check all commits to Theano and Jobman (official tools).
+    - If the official reviewer is not the right person for the task (gpu code, ...)
+      he has the responsability to find someone else (ask people in the lab, mailing-list, ...).
+    - The official reviewer should:
+         - Review all code (see the checklist) and ask an expert when needed.
+         - Commit easy fixes and ask the original committer to review them
+           (non-trivial fixes are the responsibility of the original committer).
+    - The official reviewer is chosen among the Theano users in the lab with commit rights.
+    - In this test, we ask the official reviewer to review all commits from one day.
+    - We will set up a list of experts by domain (gpu, optimization, algo,...).
+    - After this test, we may want to make it longer (1 week?)
+         - If somebody breaks the build bot, he becomes the reviewer for the next week/days.
+         - Maximum of one week by month.
+         - If there is a big week or a rush that includes everybody in the lab, we can change more frequently.
+         - If a commit has problems, the original reviewer should follow-up on it.
 
-Some system that we should check:
----------------------------------
+Other general comments:
+- We should never be the official reviewer of our own code. When this happens,
+  ask the reviewer for the next day to take care of it.
+- Experimental code (not in Theano) may be tagged as not being reviewed (in
+  commit message).
+
+Checklist for review
+--------------------
+
+- Are there tests and do they cover all cases?
+- Is there documentation in the code file?
+    - Should public (HTML) documentation be updated as well?
+- Are additions well integrated into our framework?
+- Is the code placed in the right files, and the right place in those files?
+- Try not to duplicate code.
+- Is the code clear and easy to understand?
+- Are there comments describing what is being done?
+- Answer potential questions by the committer (in the code). This can also help to train people.
+- Check for typos.
+- No debug code (print, breakpoints, ...).
+- If commit message says not to review, check that the code is disabled by default and that when enabled prints a warning.
+- Check for conformity to our coding guidelines.
+
+Some system that we checked
+---------------------------
+
+- `Review Board <http://www.reviewboard.org>`_
+    - Interesting, but some questions remain (how well it integrates with hg,
+      notably)
+    - 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
+      http://code.google.com/p/theanoclone/
+    - post-commit
+    - no list of not reviewed commit
+    - no python syntax highlight
+    - weird comment by line
+    - diff of merge seam bugged
+    - Maybe
+
+- `Kiln <http://fogcreek.com/Kiln/LearnMore.html?section=StartReviewsEffortlessly>`_
 
 - `rietveld <http://code.google.com/p/rietveld/>`_
     - Made by Guido van Rossum, seam basic and svn only
@@ -26,13 +104,6 @@
     - git only
     - No
 
-- `Review Board <http://www.reviewboard.org>`_
-    - Interesting, but some questions remain (how well it integrates with hg,
-      notably)
-    - 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
-
 - `Code Striker <http://codestriker.sourceforge.net/>`_
     - hg added? David told in May 2009 it can do it easily.
     - Seems less interesting than Review Board
@@ -45,21 +116,16 @@
     - Could be integrated with the current ticket system?, not maintained, review code in general, not commit.
     - No
 
+- `track CodeReviewPlugin <http://trac-hacks.org/wiki/CodeReviewPlugin/Concepts>`_
+
+- `track ExoWebCodeReviewPlugin <http://trac-hacks.org/wiki/ExoWebCodeReviewPlugin>`_
+
 - `feature request at assembla <http://feedback.assembla.com/forums/5433-feature-requests/suggestions/253297-add-a-code-review-tool-e-g-reviewboard->`_
     - No (we will not wait until the feature is added...)
 
 - `JCR <http://jcodereview.sourceforge.net/>`_
     - No
 
-- `Google Code <http://code.google.com/>`_
-    - Test bench with a clone of Theano at
-      http://code.google.com/p/theanoclone/
-    - post-commit
-    - no list of not reviewed commit
-    - no python syntax highlight
-    - weird comment by line
-    - diff of merge seam bugged
-    - Maybe
 
 What we could want from our code review
 ---------------------------------------
@@ -96,44 +162,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.