GSoC 2013 application: Difference between revisions

GNU Octave (http://www.gnu.org/software/octave/) is a free numerical computing environment largely compatible with Matlab. It is an old project, started in 1992 by [[John W. Eaton]] and used by hundreds of thousands of people worldwide as a free alternative to Matlab.

GNU Octave has an extensive core of functions useful for numerical computations in several fields, such as numerical analysis, optimisation, signal and image processing, and control theory. In order to speed up development, increase user contributions and test code before it is included in GNU Octave's core set of functions, a sister project, Octave Forge (http://octave.sourceforge.net/), hosts many field-specific packages.

Yes, in 2012. We've participated during 2011 and 2012 under GNU. Additionally, in 2012, we also mentored two students under ESA's Summer of  

Code... IN SPACE.

Octave has participated during the last two years with four students under the auspices of the GNU project. Due to the success of those experiences, where many members of the Octave community helped mentor the student, we want to try again.

We hope to get good code from interested students and ideally establish a line of collaboration with them for the future. We also want to raise awareness of Octave amongst the free software community.

Google Summer of Code represents a unique opportunity to pump up work into highly needed low level improvements to Octave, as well as high level field-specific functionality. We believe the interaction with fresh minds will bring not only new code to Octave but also will augment the developers group.

Yes, during 2011 and 2012, under the GNU umbrella. Four students have successfully completed projects for us in the past, all of which is live and in our main source tree. In addition, we mentored two students in 2012 through the European's Space Agency's independent Summer of Code In Space.

The challenges have been about managing very diverse problem domains and finding people who are competent in all of them.  We have not had great trouble keeping students interested, although we've seen lulls in their productive output a few times, which were always thankfully remedied with a little prodding.

Mentors have been chosen based on their expertise in the field of the corresponding project, either based in their past contributions to Octave or in their academic background or their current professional activities, as well as on their involvement in the mailing list and the quality of their past advice. Preferrably they already have code in the Octave source tree and ideally already have commit access to our source tree. Also whether they can participate in chat sessions, but this is less important.

First, make all reasonable efforts to accomodate the student and make them feel welcome. Frequent contact with the student, prompt response to student queries, periodic status reports from mentors about the contact of the student. Also encourage the student to participate in the public mailing list and IRC channel, with or without mentor. Their progress should be regularly applied to our source tree, if necessary, in a feature branch.

Should this fail and the student disappears for unforeseen reasons (which we hope will be very unlikely, and nobody vanishes without good reason), make reasonable attempts to contact them first, of course, up to and including using a phone number if one was provided. If enough time has passed without response (say, two weeks without a response, after attempting all methods), begin to analyse the code they have submitted, and attempt to integrate it into our source tree.

Distribute the workload amongst the remaining mentors. The mailing list is active enough and questions almost never go unanswered. Reassign the student to a backup mentor. In the worst case, the project admin can become a mentor for the student until another backup mentor is found.

This should be infrequent and we hope to prevent this to begin with by selecting mentors with proven involvement in Octave or other free projects. We will also pair new mentors with older ones.

Invite them to IRC. Set clear expectations on the minimum frequency of email progress updates (probably every two or three days). Be nice and friendly to them.

Everything should be very open. Almost all interactions with the student should be public, so that e.g. contacting the mentor should happen in the public IRC channel or CC'ing the public mailing list. For shy students, The reports should be on a blog. The blogs will be aggregated at http://planet.octave.org.  

For some projects, there may be way to bridge them directly into industry projects. We hope that we can increase the student's participation this way.

We will encourage students and mentors to keep in touch after the program. We will integrate as soon as possible the code into our codebase, and we will forward bugs and positive feedback directly to the responsible students. Possibility of the student staying after GSoC will be our primary concern when selecting students.