Hi folks: Per http://www.google-melange.com/gsoc/events/google/gsoc2012 the period during which organizational applications are accepted for the Google Summer of Code 2012 is February 27th through March 9th. We're getting close to the starting gate, and I'd much rather have an application in early than cut it close to the wire _if_ we want to participate again this year.
Thus, a quick set of thoughts of what we need to do: 1) Review and refresh our http://evergreen-ils.org/dokuwiki/doku.php?id=dev:summer_of_coding_ideas wiki page to ensure that the ideas are still desired, capture a good, interesting list off the projects that we think are attainable by a computer science student through the course of a summer, and ensure that the page itself gives appropriate guidance to prospective students. Steps that I've taken thus far: * Revised the "Contacting us" section to break it out into org administrators (Galen and I) and mentors (Thomas and I, so far) * Removed the "Overhaul config madness" entry that Joe Lewis addressed during last year's GSoC project * Revised the i18n project to reflect the predominance of the TPAC and the potential to standardize further on TPAC for UIs and internationalization I've also noted that others have adjusted the page to offer information on getting started with a new developer's virtual image. Can I suggest that we break most of that information out into a separate page? I thin it currently makes the page pretty top-heavy with technical info rather than introducing potential applicants to our community - and the virtual image is a valuable resource in and of itself! I think we should also build on some of the lessons learned from last year's GSoC experience: a) State clearly that our goal is to enable students to experience success in contributing working code to our project. For example, as noted in my reflections on GSoC 2011, I think we made a mistake last year in creating separae student repos rather than treating students like any other contributor and expecting them to use the working repos. Based on my discussions with other projects at the GSoC mentors' summit, I also think it is more important to get code from the students committed early (with accompanying follow-up commits from mentors that address small mistakes) than to force them to attain perfection prior to submission. Last year we allowed code to drift in branches for long periods of time, as we attempted to teach them how to create "perfect" submissions, but that can have a negative effect on morale and slow down the willingness to put forward code for integration. In short, we want the experience to be positive for the student, mentor, and project. b) State clearly that we expect students to communicate publicly with the project, either via blog posts or posts to the mailing list, on a regular basis (I would suggest weekly as a minimum bar). And more communication should also be occurring between the student and the development team on a daily basis through the normal modes of IRC, bug tracker, and mailing list. c) Introduce and enforce a requirement that any student applications _must_ submit a patch or point to a branch that addresses some problem or adds some small enhancement. Bite-size bugs are good candidates. If people want to tag some more bugs as 'bitesize' that would be a good use of time. (If you think that this is a barrier to applicants, then bingo: that's definitely the goal. If you saw how many applications we had to wade through last year, you would understand why we want to have more of a barrier to entry this time around). 2) We need to firm up the list of willing mentors for this summer. Mentors must have time available each week (some estimates suggest 10 hours / week) to provide assistance to a new developer in the project; you must be willing to help nurture a new developer; and you must be technically capable of Evergreen development (including all of our norms around git usage, etc). Prospective mentors are advised to consult the "Google Summer of Code Mentors Guide" at http://en.flossmanuals.net/GSoCMentoring/ (heck, it contains a lot of accumulated wisdom about GSoC, it's worth browsing if you're just interested in the program). 3) I guess we should confirm that we actually do want to participate again this year, although my gut tells me "yes" we haven't really had any developer meetings for quite some time. For what it's worth, Galen did ask the Oversight Board and the initial reaction, at least, is that they're cool with us participating again. That's a quick brain dump on what I think we need over the course of the next week or so, based on my experiences & lessons learned from last year. Other thoughts would be greatly appreciated! Dan