--- a/doc/v2_planning/coding_style.txt	Thu Sep 09 13:01:30 2010 -0400
+++ b/doc/v2_planning/coding_style.txt	Thu Sep 09 13:21:20 2010 -0400
@@ -32,7 +32,6 @@
 Dumi: we should also try to find tools that automate these
 processes: pylint, pyflakes, pychecker, pythontidy
 
-OD: I think PEP8 + Google guidelines are a good basis.
 OD: Things about PEP 8 I don't like (but it may be just me):
 
    * If necessary, you can add an extra pair of parentheses around an
@@ -108,8 +107,48 @@
 
 We also need a c-style coding style.
 
-Meetings
---------
+Meeting 2010/09/09
+------------------
+
+   * Coding guidelines
+PEP 8 & Google should be a good basis to start with.
+Task: Highlight the most important points in them (OD).
+
+   * Documentation
+Use RST with Sphinx.
+Task: Provide specific examples on how to document a class, method, and some
+specific classes like Op (DE).
+
+   * Python versions to be supported
+Support 2.4 (because some of the clusters are still running 2.4) and write
+code that can be converted to 3.x with 2to3 in a straightforward way.
+Task: Write to-do's and to-not-do's to avoid compatibility issues. (OD)
 
-   * Thursday 2010/09/09, 11 am
+   * C coding style
+How to write C code (in particular for Numpy / Cuda), and how to mix C and
+Python.
+Task: See if there would be a sensible C code style to follow (maybe look how
+Numpy does it), and how projects that mix C and Python deal with it (e.g. use
+separate files, or be able to have mixed syntax highlighting?) (FB)
+
+   * Program output
+Use the warning and logging modules. Avoid print as much as possible.
+Task: Look into these modules to define general guidelines e.g. to decide when
+to use warning instead of logging. (DWF)
 
+   * Automatized code verification
+Use pychecker & friends to make sure everything is fine.
+Task: Look into the various options available (DE)
+
+   * Tests
+Force people to write tests. Automatic email reminder of code lines not
+covered by tests (see if we can get this from nosetests). Decorator to mark
+some classes / methods as not being tested yet, so as to be able to
+automatically warn the user when he is using untested stuff (and to remind
+ourselves we should add a test).
+Task: See feasibility. (OD)
+
+   * VIM / Emacs plugins / config files
+To enforce good coding style automatically.
+Task: Look for existing options. (FB)
+