Re: [boost] GSoC 2011 - Do we need to starting thinking about it?

Subject: Re: [boost] GSoC 2011 - Do we need to starting thinking about it?
From: Darren Garvey (darren.garvey_at_[hidden])
Date: 2011-01-24 13:07:05

On 24 January 2011 17:16, Andrew Sutton <asutton.list_at_[hidden]> wrote:

> >
> > >I recall that last year, Boost didn't start thinking about possible
> > projects
> > > to suggest to potential GsoCoders until rather late.
> > >
> > > Perhaps we should *start* thinking reasonably soon?
>
> I'd like to run things differently this year. Specifically, I want to:
> 0. Encourage much higher quality proposals
> 1. Accept proposals for experimental (sandbox) libraries
> 2. Accept multiple, competing proposals for the same library
> 3. Encourage longer-term relationships by considering multi-year
> commitments
>

Add to this:

4. All students should submit a miniature, self-done aptitude test as part
of their proposal. The Boost build / test / doc chain can be a big
motivation-killer for students who just want to get on with coding. Getting
that step done before the SoC starts would help mentors decide on the best
candidates and give the students a bit of a head start.
5. Encourage toolkit-like additions to existing libraries, rather than
writing a full-blown library. These have historically been more successful.

> Proposals in the 3rd category are also particularly interesting, since they
> provide a method of funding a student with a particularly interesting
> long-term project over a number of years. My goal would be to encourage
> seemingly good and particularly ambitious students to revise a 1-year
> proposal to span multiple summers. A student that successfully completes
> the
> first summers goal, would automatically receive a funding line for the
> following year unless a) they forfeit their funding over the Fall or
> Spring,
> b) fail to submit a proposal the following year, or c) we don't get any
> funding. Obviously, the number of multi-year lines would need to be capped.
>

This makes sense considering in many cases only the smallest projects have
been actually completed in one summer (with a few notable exceptions:
Phoenix v3, Python 3.0 support for Boost.Python, Boost.Bimap,
Boost.Process).

It would be even better if we could fund students part time over the Fall
> and Spring, but that's a whole other can of worms :)
>

+1 :)

> So... with regards to a project page: I would suggest the following:
> project
> ideas should give some very general concepts with some short explanation,
> and a list of mentors. For example:
>
> Project: Strings and Encodings
> Strings are sequences of n-byte characters, whose values may be interpreted
> by different Encodings (e.g., UTF-8, Base64, Quoted-Printable, etc.).
> Mentors: Bob Smith, Fred Jones
>

+1

> Instructions on the page direct students to a) search the Boost mailing
> list
> archives for previous discussion on the topic and b) contact the mentors
> (preferably on list) to discuss the basic expectations for the project.
> Note: *expectations* not *requirements*. It should be up to the student to
> generate a proposal that identifies the requirements of the project.
>

+1

Cheers,
Darren