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).
Junio C Hamano wrote:
Ramkumar Ramachandra [off-list ref] writes:
quoted
[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.
The short undiplomatic version of that is that our mentors suck (I'm
not pointing fingers, but that's what I infer from failing projects).
In my opinion, there is no point putting up proposed mentors for
projects in advance: ideal mentors are people who are interested in
the students, more than the project proposals.
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.
The Wiki is often polluted with arbitrary, useless, unrealistic
projects. We expect students to pick up from a small writeup on the
Wiki and come up with everything else, and I think this is a mistake.
Further, I think burdening one pre-chosen mentor with all the
groundwork is a terrible idea.
I propose that we have one thread for every proposal where we can all
discuss the implementation outline- this will serve as authoritative
source of information for students, and for picking mentors (the
people who contribute most to the discussion). Students should be
matched with mentors on an individual basis.
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.
The discussion thread will automatically tell us which projects are
badly thought-out and unrealistic.
Ramkumar Ramachandra wrote:
The short undiplomatic version of that is that our mentors suck (I'm
not pointing fingers, but that's what I infer from failing projects).
Hold on a second. I'm not remembering such a grim outcome with 100%
failure from prior summers of code as you're describing. Before I
start beating myself up, I guess I'd like a little more information
--- is there some specific project or statistic that you're thinking
of that brings you to that conclusion?
[...]
I propose that we have one thread for every proposal where we can all
discuss the implementation outline- this will serve as authoritative
source of information for students, and for picking mentors (the
people who contribute most to the discussion). Students should be
matched with mentors on an individual basis.
How is that different from what happened in previous summers where
students made proposals, received feedback, and were accepted and
matched to mentors or rejected based on how the discussion went?
Jonathan
Jonathan Nieder wrote:
quoted hunk
Ramkumar Ramachandra wrote:
quoted
The short undiplomatic version of that is that our mentors suck (I'm
not pointing fingers, but that's what I infer from failing projects).
Hold on a second. I'm not remembering such a grim outcome with 100%
failure from prior summers of code as you're describing. Before I
start beating myself up, I guess I'd like a little more information
--- is there some specific project or statistic that you're thinking
of that brings you to that conclusion?
In retrospect, I might have been unnecessarily harsh there.
One of the main measures of a mentor's success, in my opinion, is
having his student stick around after the Summer of Code: the mentor
is the student's primary link to the community. There have been 4~5
students every year, times 6 years (is that how long we've been
participating?). How many of those students have felt part of the
community?