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@gmail.com