Re: Google Summer of Code 2013 (GSoC13)

2 messages, 2 authors, 2016-06-15 · open the first message on its own page

Re: Google Summer of Code 2013 (GSoC13)

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:56:11

Ramkumar Ramachandra [off-list ref] writes:
Junio C Hamano wrote:
...
quoted
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).
I was conflating between people who add "suggested project" and who
act as mentors.  I do not think mentors are primarily responsible
for bad suggested projects.

Our mentors may be wonderful but I do not have enough evidence to
judge either way.  They are mostly student-facing and I as a
bystander to GSoC process didn't see much of their involvement in
their students' work---maybe that is how it is supposed to work,
maybe not.  The only failing of them observable from my point of
view was that we repeatedly saw the initial round of patches come
very late.

But my complaints were primarily about those sure-to-fail project
suggestions.
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.
You are being unreasonable and/or unrealistic. A topic that needs a
large discussion thread to pre-discuss design and outline by many
existing members of community and mentor candidates is a sure sign
that the topic is too big for a beginner. A topic that needs only a
small enough discussion thread on the other hand will come to a
polished conclusion before even the student shows up.  

This is exactly why I suggested "doable as a private, at most
two-weekend hack by an experienced" as a quick and dirty way to
measure the size of a project.

Re: Google Summer of Code 2013 (GSoC13)

From: Ramkumar Ramachandra <hidden>
Date: 2016-06-15 22:56:11

Junio C Hamano wrote:
Ramkumar Ramachandra [off-list ref] writes:
quoted
Junio C Hamano wrote:
...
quoted
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).
I was conflating between people who add "suggested project" and who
act as mentors.  I do not think mentors are primarily responsible
for bad suggested projects.
Why do mentors pick badly sketched-out projects to mentor?  They're
free to pick anything they want/ propose what they want.
Our mentors may be wonderful but I do not have enough evidence to
judge either way.  They are mostly student-facing and I as a
bystander to GSoC process didn't see much of their involvement in
their students' work---maybe that is how it is supposed to work,
maybe not.  The only failing of them observable from my point of
view was that we repeatedly saw the initial round of patches come
very late.
Ideally, the initial round of patches should come in well before the
GSoC even starts, I think (the initial round might just be doing some
minor surrounding work though).
quoted
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.
You are being unreasonable and/or unrealistic. A topic that needs a
large discussion thread to pre-discuss design and outline by many
existing members of community and mentor candidates is a sure sign
that the topic is too big for a beginner. A topic that needs only a
small enough discussion thread on the other hand will come to a
polished conclusion before even the student shows up.
I that case, projects like inotify support that Duy suggested in a
nearby thread are not realistic candidates.  No, I wouldn't like huge
discussion threads on each proposal either: but a ~10 email thread
with everyone's thoughts on it would be useful, I think.  If the size
of the thread exceeds a certain threshold, the project is deemed
un-doable automatically.
This is exactly why I suggested "doable as a private, at most
two-weekend hack by an experienced" as a quick and dirty way to
measure the size of a project.
Yes, that's a good measure.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help