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

[Lori Bowen Ayre]

Hi Dan and other Devs,

As you all probably know, I've been working on recruiting more developers
to the mix and the people I've worked with have identified some stumbling
blocks along the way.  Some of these issue probably go away when you have a
dedicated mentor (as in GSoC) but I wanted to share the wiki page we've
been putting together that identifies some areas that we'd like to flesh
out to make entry into the Evergreen developer community a bit easier.

It's here:
http://evergreen-ils.org/dokuwiki/doku.php?id=dev:new_developer_wishlist&s[]=developer


You'll see that we're identifying the pieces of info that are lacking or
hard to find and we're also got some volunteers lined up for doing the
fleshing bit.

The last section (About Funded Projects) really deals more with the funded
projects I was coordinating.  Not pertinent to the community at large as
much.

Lori

On Sun, Feb 26, 2012 at 1:13 PM, Dan Scott <dan at coffeecode.net> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20120227/74d629c8/attachment.htm>