Re: Google Summer of Code 2013 (GSoC13)

Ramkumar Ramachandra [off-list ref] writes:

[corrected David Barr's email address]

Jeff King wrote:

quoted

And I do not want to blame the students here (some of whom are on the cc
list :) ). They are certainly under no obligation to stick around after
GSoC ends, and I know they have many demands on their time. But I am
also thinking about what Git wants to get out of GSoC (and to my mind,
the most important thing is contributors).

As far as merged code, I think part of the problem is that git is fairly
mature at this point. The most interesting projects are of a bigger
scope than a student with no experience in the code base can do in a
summer project. Maybe that means we need to do a better job of breaking
projects down into reasonably sized sub-components. Or maybe it means
the project is hitting a point of diminishing returns for GSoC. I don't
know.

Also, we need more projects that will scratch everyday itches.  A
collection of related tiny features might not be a bad idea.  Often,
we risk erring on the side of too-big-for-one-summer when it comes to
specifying projects.  What's the harm of including something estimated
to take 80% of a summer?

I think the real issue is everybody in the GSoC mentor candidate
pool grossly underestimates the scope of suggested projects, does
not encourage students to send early drafts to the public from the
beginning, and perhaps overestimates the ability of total beginners.
After seeing my "index-thing is too big in scope" warning repeatedly
ignored for the last year's GSoC, I am not very hopeful unless the
attitude towards GSoC and its students drastically changes on our
mentors' end.

We have solicited "suggested projects" entries via wiki in the past,
letting anybody to put anything there, and I think that was a major
source of our past failures.  The practice lets irresponsive people
who think they know what they are talking about to place unrealistic
pie-in-the-sky there.  I wonder if we can somehow come up with a way
to limit them to realisitic ones in a sane way.  One possibility may
be to require the proposer to already have an 80% answer, not to be
shared with students.  A project that a GSoC student who is not
familiar with our codebase and culture (e.g. our no regressions
policy and requiring solid transition plan for disruptive changes)
is expected to finish in a summer should not be bigger than what a
mentor familiar with our project can do a rough outline design and
implementation as a two-weekend hack at most, I think.

Such a requirement on the proposer's end may be a reasonable sanity
check to make sure we do not suggest sure-to-fail projects to the
students.

It is ironic that I have to point out that the best "let's get
students exposed to the OSS process using Git community's reviewing
bandwidth" last year from my point of view happened outside the
GSoC.  Matthieu's school projects were not structured to the GSoC
standard (they assigned multiple students working together on each
topic), but the size of the projects seemed more manageable.  It was
a joy to work with these students during the term of the project. We
had a meaningful number of review iterations, unlike a typical GSoC
project where a student and her mentors sit in a dark cave for a
long time, send out the first draft too late, and the participant do
not get enough time to do meaningful iterations of reviews (it was
also a huge plus from our project's point of view that there were
even responsible post-program follow up to complete the unfinished
bits).