Junio C Hamano wrote: > Ramkumar Ramachandra <artagnon@xxxxxxxxx> 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. 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. -- 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