--- a/doc/v2_planning/coding_style.txt	Thu Sep 16 13:14:19 2010 -0400
+++ b/doc/v2_planning/coding_style.txt	Thu Sep 16 13:28:35 2010 -0400
@@ -400,6 +400,8 @@
       define all and any.
       OD: I think we should have something like pylearn.compat.{all,any}.
           numpy.{all,any} are meant to be used on arrays only.
+      OD: As agreed during committee's meeting, we will use
+          theano.gof.python25
 
     * Do not use the `hashlib` module (not supported in Python 2.4).
       You can do as in theano.gof.cc:
@@ -415,6 +417,15 @@
     OD: Yep, we could probably come up with such a wrapper in a pylearn.compat
         module.
 
+    * Do not use mutable arguments as default values. Instead, use a helper
+      function:
+      Yes:
+        def f(array=None):
+            array = pylearn.if_none(array, [])
+      No:
+        def f(array=[]):
+            # Dangerous if `array` is modified down the road.
+
 Mercurial commits
 -----------------
 
@@ -422,6 +433,9 @@
     OD: Check Django's guidelines (link above)
    * Standardize the merge commit text (what is the message from fetch?)
 
+During committee's meeting, Fred mentioned a bug with Assembla links for
+multi-line commits.
+
 Type checking
 -------------
 
@@ -451,6 +465,9 @@
 vous pourriez p-e définir des type/value-checkers standards pour éviter que
 tout le monde redéfinissent les siens à sa façon.
 
+OD: This was discussed in committee's meeting. We agreed to provide ways to do
+this, but not to enforce its usage.
+
 Consistent inf / nan
 --------------------
 
@@ -458,6 +475,7 @@
 (should be slightly more efficient even if efficiency usually doesn't matter
 here - the main goal would be for everyone to use the same inf / nan to make
 the code consistent).
+OD: Approved during committee's meeting.
 
 Enforcing strict testing policy
 -------------------------------
@@ -492,5 +510,14 @@
 Meeting 2010/09/16
 ------------------
 
-(in progress)
+Tasks to be performed by tomorrow:
+    * OD:
+        * Write down summary of Python coding style recommendations
+        * Start a file that showcases those guidelines
+    * DWF:
+        * Look into recommendations on how to document a class, method, ...
+        * Write recommendations on when to use logging vs. warning
+        * Make public some configuration files / plugins for vim
+        * Come up with official common file header (license in particular)
 
+