[OPEN-ILS-DEV] Google Summer of Code 2012

[Dan Scott]

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