Ramkumar Ramachandra <artag...@gmail.com> 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. 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). -- 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
