diff --git a/GSoC-2015-Ideas.md b/GSoC-2015-Ideas.md
index 230028a..2a81fd1 100644
--- a/GSoC-2015-Ideas.md
+++ b/GSoC-2015-Ideas.md
@@ -281,6 +281,10 @@ GLFW backend. This will allow games to be created more idiomatically and with
 less overhead involved. Other new languages like Rust have similar projects
 like [Piston](https://github.com/PistonDevelopers/piston).
 
+This requires the idiomatic and platform independent implementation of 2D
+graphics and 3D graphics, window management as well as audio output. By using
+SDL2 we also ensure that porting to mobile platforms will be easier.
+
 **Tasks:**
   * Start implementing a high level game library on top of SDL2 and OpenGL, inspired by other game libraries like Piston and Pyglet.
   * Prove the usability to write a simple Minecraft clone in the spirit of the 500 line Python/Pyglet [Minecraft](https://github.com/fogleman/Minecraft).
@@ -303,10 +307,20 @@ parallel programs. These programs can run on a single computer as well as on a
 whole cluster, where messages are sent over the network. Nim, with its
 excellent performance/productivity ratio, would make a great language for this
 use. What's missing is a Nim library to make use of the existing MPI libraries
-for C. An existing C library like OpenMPI can be wrapped using `c2nim` to get a
-non-idiomatic low level wrapper for MPI. Since the MPI interface is very
-verbose, and to make its use feel more Nim-like, a high level library should
-then be written.
+for C. An existing C library like [OpenMPI](http://www.open-mpi.org/) can be
+wrapped using `c2nim` to get a non-idiomatic low level wrapper for MPI. Since
+the MPI interface is very verbose, and to make its use feel more Nim-like, a
+high level library should then be written.
+
+A possible source of problems is that MPI libraries often differ slightly. For
+the start it will be good enough to just support one of the popular MPI
+libraries like OpenMPI or MPICH. Afterwards it will be interesting how to deal
+with the C preprocessor macros specifying the differences between MPI
+implementations. You will need to investigate whether a solution such as [in
+Julia](https://github.com/lcw/MPI.jl/blob/master/deps/make_f_const.f) will be
+necessary to create a custom wrapper for each MPI implementation. Preferrably
+this would be solved directly with Nim's capabilities, and the close relation
+to C could come in handy here.
 
 **Tasks**:
   * Create a low level wrapper of a C library for the MPI standard using `c2nim`.
@@ -328,12 +342,16 @@ then be written.
 
 Gofmt is often cited as one of the major points for the Go programming
 language. It completely eliminates the need to manually adhere to style
-formatting, by automatically converting Go code into a consistent style.
+formatting, by automatically converting Go code into a consistent style. This
+makes the code easier to read, write and maintain as well as removes any debate
+about which code style to adhere towhich code style to adhere to
+
 Something similar would be nice to have in Nim, where we have additional
 freedoms, like case insensitivity, that should be handled in a consistent way
-for big projects.
+for big projects. Such a project could be closely tied to the Nim compiler,
+that already brings the tools to parse Nim code and represent it in AST form.
 
-There is already a converter from AST to Nim code in
+There is already a converter from AST to Nim code as well, in
 [renderer.nim](https://github.com/Araq/Nim/blob/devel/compiler/renderer.nim),
 that is used for `repr` as well as `c2nim`. It would make sense to use and
 extend this or at least use it as inspiration.