On Thu, Feb 24, 2011 at 7:55 PM, Brian Gruber <br...@iheardata.com> wrote:
> First, I can't tell you how happy I am to have such an enthusiastic response
> from this community. Just a word of warning: per google's rules, two
> students can't work together on one project.
> /brian

> On Thu, Feb 24, 2011 at 11:02 AM, Eric Caspary <caspary.e...@gmail.com>
> wrote:

>> I'd be thrilled to work on Overtone as a Google SoC project. I'm
>> currently in the middle of my Master's studies and in the market for
>> an internship. I've been using Overtone with clj-processing since late
>> November and have some familiarity with the internals. If Jeff and Sam
>> have any ideas in mind, perhaps Vilson and I can tackle them in
>> tandem.

>> _
>> Eric

>> On Feb 24, 9:28 am, Vilson Vieira <vil...@void.cc> wrote:
>> > Hello Brian and Sam,

>> > I'm starting a master program at March as special student and maybe I
>> > could
>> > join on that. So interesting.

>> > Cheers.

>> > 2011/2/24 Brian Gruber <br...@iheardata.com>

>> > > On Feb 23, 2:18 pm, Sam Aaron <samaa...@gmail.com> wrote:
>> > > > Hey Brian

>> > > > Brian Gruber wrote:
>> > > > > Awesome. I can't wait to hear your ideas.

>> > > > Do you have any information on the scope of a typical project? I'd
>> > > > like
>> > > > to try to make any suggestions fit into the expected remit rather
>> > > > than
>> > > > be either too ambitious or trivial.

>> > > It's somewhat difficult to say, because the scope is largely dependent
>> > > on the student. Students are expected to spend 30-40 hours per week on
>> > > their project for 13 weeks. This sounds like a lot, but remember that
>> > > students new to Overtone may have to take some time to get familiar
>> > > with the code base. My own 2007 project, for example, was fairly
>> > > small, but I was an almost complete Lisp neophyte at the time. At the
>> > > other end of the spectrum, in 2006, someone implemented an STM for
>> > > Common Lisp. LispNYC wants a variety of difficulty levels if we can
>> > > get it.

>> > > Some more definite ideas: the project should have some sort of end-
>> > > goal, so that everyone can agree as to whether or not the student
>> > > completed the work. E.g. "Make X better" is not a good project; "Add
>> > > feature Y to X" is. A project that has a visible benefit to the open
>> > > source community (or can be spun that way) is also good.

>> > > /brian

>> > --
>> > Vilson Vieira

>> > vil...@void.cc

>> > (((http://automata.cc)))

>> > (((http://musa.cc)))