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: Andrew Sutton (asutton.list_at_[hidden])
Date: 2011-01-24 12:16:33

>
> >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?
>
> What about starting by the addition of an empty wiki page and let people
> push his proposals https://svn.boost.org/trac/boost/wiki/SoC2010
>

It's probably time to start thinking in this direction again, It feels like
SoC 2010 just ended :) Since the topic came up, I guess I'll give a little
info-dump on what I'd like for GSoC this year. After talking to a number of
people at the GSoC Mentor Summit, I don't think that writing up a project
list the same way that we have been doing is a good approach for Boost.
There are two reasons for this.

First, we've done that the last two years and the overwhelming majority of
applications have been of the form, "I will do xxx". Even when we do pick
students who can do xxx, they're here for the summer and then gone, and
nothing happens with their work. It's really not that surprising given the
amount of effort required to master the various programming styles and
techniques found in Boost much less get a project accepted as part of the
distribution. Single-summer projects are either too big or too small.
Historically, we haven't been to good about finding "just right".

Second, the process of picking student projects has less to do with students
proposing good projects, but rather finding mentors that are interested in
getting projects done. We gave up 3 funding lines last year because there
weren't enough mentors willing to work with the kinds of projects that had
been suggested off our "menu". There are a number of reasons we ran into
this problem. We all tend to fixate on our own little domains and needs and
so there aren't many general purpose mentors. Disagreement (on the mailing
list) about the design of a particular proposal can discourage students and
mentors. I'm looking at you XML library :) Also, there seems to be a
reluctance to mentor for sandbox projects because they aren't "part of
Boost" and there's no guarantees on when or even if they will become part of
the main distribution.

Basically, the formulaic project list does not encourage proposals for the
kinds of work that a) has broad appeal, b) does not benefit our (broader)
community, and c) may not provide the visibility that students are looking
for (i.e., projects lacking "sex appeal").

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

Proposals in the 1 and 2 category should be of great interest to the broader
community since they give us an opportunity to evaluate experimental and
competing designs for new data structures, algorithms, libraries, etc. Also,
if we don't get projects in the #2 category, then we end up spending a lot
of time discussing tradeoffs and details on the mailing list (see the
current string discussions). Accepting proposals of this form can give us
great data points for building new Boost libraries and features, which is
even more important when those may wind up as ISO C++ proposals (TR2, etc.).
Plus, this gives us an opportunity to get more students involved.

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.

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 :)

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

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.

Thoughts?

Andrew Sutton
ansutton.n.stutton_at_[hidden]