Re: Google Summer of Code 2013 (GSoC13)

> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> [corrected David Barr's email address]
>>
>> Jeff King wrote:
>>> 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.