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