Junio C Hamano wrote:
> Ramkumar Ramachandra <artag...@gmail.com> writes:
>> Junio C Hamano wrote:
>>> 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).
>> 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
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html