On 24 January 2011 17:16, Andrew Sutton <asutton.list@gmail.com> 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