SOC application draft

The deadline for mentoring organisations is this Wednesday, so we really need to get organised - in particular we need a preliminary list of mentors by that time! In the mean time at Jeff's suggestion I've attached below a draft of our application so you all get to critique it :-) Regards, John. Here comes the draft.... 1) What is your Organization's Name? Boost C++ Libraries 2) What is your Organization's Homepage? www.boost.org 3) Describe your organization. Boost provides free peer-reviewed portable C++ source libraries. We emphasize libraries that work well with the C++ Standard Library. Boost libraries are intended to be widely useful and usable across a broad spectrum of applications. The Boost license encourages both commercial and non-commercial use. We aim to establish "existing practice" and provide reference implementations so that Boost libraries are suitable for eventual standardization. Ten Boost libraries are already included in the C++ Standards Committee's Library Technical Report (TR1) as a step toward becoming part of a future C++ Standard. More Boost libraries are proposed for the upcoming TR2. 4) Why is your organization applying to participate in GSoC 2008? What do you hope to gain by participating? Our aim in applying is twofold: to nurture long term Boost and/or other open source participation, and to obtain useful contributions to the Boost C++ libraries. In past years we believe we have achieved both of these aims, and would like to do the same this year. 5) Did your organization participate in previous GSoC years? If so, please summarize your involvement and the successes and failures of your student projects. (optional) We participated in 2006 and 2007. In 2006 we had 9 students: three of these projects have resulted in completed libraries being added to the Boost project, and two of the students have become long term contributors. Five other projects were completed successfully, but the students ran out of time before polishing the library to a sufficient standard for Boost submission: none the less these represent significant bodies of work that will shape future development efforts in these areas. In 2007 we had a couple of students drop out, of the remaining 6 projects, one has been integrated into Boost and the student gone on to be a significant Boost contributor, three others have been under continued active development through last Autumn - we hope to tempt more students back once their college commitment allows. 6) If your organization has not previously participated in GSoC, have you applied in the past? If so, for what year(s)? (optional) Nothing to say here 7) What license does your project use? The Boost Software License: http://www.boost.org/LICENSE_1_0.txt See also: http://opensource.org/licenses/bsl1.0.html 8) URL for your ideas page http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?Google_Summer... 9) What is the main development mailing list for your organization? http://www.boost.org/more/mailing_lists.htm#main 10) Where is the main IRC channel for your organization? http://www.boost.org/more/mailing_lists.htm#IRC 11) Does your organization have an application template you would like to see students use? If so, please provide it now. (optional) Introduction: Introduce the main concepts around the project: Theoretical preliminaries, pre-existing Boost libraries used (if any), important concepts, problems/needs the project will try to solve/satisfy. Goal: Concise statement of the overall goal of the project. Refine this initial statement to include: project deliverables (code, docs, testing), required/suggested methodology, standards of quality, possible goal extensions beyond the main objective. Requirements: List the requirements and level of expertise you estimate the student will have to meet: Required level of C++, specific areas of the language (STL, templates, locales, whatever), level of familiarity with Boost and particular Boost libraries, development/documentation/testing tools, mathematical/algorithmic background, other desirable skills. Other sections: If you have more to say about the project that doesn't fit in the proposed sections of this template, feel free to add other sections at will. Oh, and don't forget to separate each entry with a horizontal line, entered at the edit box as ---- 12) Who will be your backup organization administrator? Please enter their Google Account address. We will email them to confirm, your organization will not become active until they respond. (optional) jz.maddock@gmail.com Mentors ~~~~~~~~ 1) What criteria did you use to select these individuals as mentors? Please be as specific as possible. We only use existing Boost library authors as mentors: people who have been through the Boost submission process already and know their way around the project. Ultimately the moderators of the Boost library project have final say on who acts as a mentor - our aim is to seek out the existing authors with the best development practices and persuade them to mentor! 2) Who will your mentors be? Please enter their Google Account address separated by commas. If your organization is accepted we will email each mentor to invite them to take part. (optional) TODO: Mentor list here!!!! About the program ~~~~~~~~~~~~~~~~~ 1) What is your plan for dealing with disappearing students? Whilst we have to accept that ultimately some students will be bound to drop out, we do try and avoid this as far as is possible. In the application process we look for enthusiasm, communications skills, and community participation as well as technically good applications: if we are able to select students who "can't wait to start" then that tends to reduce the initial dropout rate. Once the project starts we try and ensure that the students have regular contact with their mentors and plenty of help and encouragement to continue where required: while still trying to ensure that the students have the opportunity to explore and grow into the project and explore their own ideas. This is a fine line to draw, and one we will no doubt never get completely resolved! 2) What is your plan for dealing with disappearing mentors? We've never had a mentor disappear, but in the last two years we ended up with more mentors than students, so if necessary we have had backup mentors available. We also have a dedicated mailing list for the students: useful if they need a response faster than their mentor can provide. In the event of a student/mentor dispute then the Boost moderators are available to help resolve things - thankfully we haven't needed that so far. 3) What steps will you take to encourage students to interact with your project's community before, during and after the program? We encourage students to interact on the mailing list and discuss and refine project ideas prior to submission: in the past this has resulted in much improved project submissions, and a reasonable indicator of which students are likely to continue this interaction during and after the project. 4) What will you do to ensure that your accepted students stick with the project after GSoC concludes? As well as encouragement to continue, we try to provide students with detailed feedback on their progress towards getting their contributions formally accepted into Boost, so that they know exactly what needs to be done to complete the project. Although progress after the SOC period ends tends to be slow - we still have SOC 2006 projects being actively worked on - none the less we have been pleased with the continuing involvement of past students.

On Mon, Mar 10, 2008 at 12:01 PM, John Maddock <john@johnmaddock.co.uk> wrote:
In 2007 we had a couple of students drop out, of the remaining 6 projects, one has been integrated into Boost and the student gone on to be a significant Boost contributor, three others have been under continued active development through last Autumn - we hope to tempt more students back once their college commitment allows.
I really appreciate the "once their college commitment allows" comment :-). Anyway, I just posted a review request for my project, if that helps any.
4) What will you do to ensure that your accepted students stick with the project after GSoC concludes?
As well as encouragement to continue, we try to provide students with detailed feedback on their progress towards getting their contributions formally accepted into Boost, so that they know exactly what needs to be done to complete the project. Although progress after the SOC period ends
I found this to be a critical issue for myself - after the end of last SOC I found myself with a lot of great feedback on how I can improve the library I was working on, but at the same time I wasn't sure what was crucial to make the library review-ready. I think a mini-review at the end of SOC that would focus specifically on what's left to be done (as far as boost review/inclusion goes) for all of the projects would be really really helpful (I think things like this have been suggested before, but it didn't seem to quite happen last time). Thanks to all boost mentors and admins for your work in coordinating Boost-GSoC, it's a really rewarding experience for us students! Stjepan
participants (2)
-
John Maddock
-
Stjepan Rajko