Hi, On Sat, Oct 19, 2013 at 8:09 AM, Thomas Rast <t...@thomasrast.ch> wrote: > > Previous Episodes > ================= > > Git participated in Google Summer of Code (GSoC) 2007-2012, but did not > participate in 2013 based on discussion in February [1]. At Git-Merge > in Berlin there was a discussion round [2] that this post attempts to > summarize as a basis for further discussion and (hopefully) > participation in GSoC'14. > > Much sooner than in previous years, Google has already confirmed that > GSoC'14 will in fact happen [3]. > > Note that while mistakes herein are mine, many ideas and opinions > aren't. This really tries to be a summary. Please flame >/dev/null, > not me.
Thank you for sending this very good summary. > Theories > ======== > > These are the hypotheses that I have heard (mostly in [1] and [2]) as > to what is bad about Git's prior GSoC participations. > > * Aiming far too high, focusing on cool/shiny projects with a large > impact. This also affects the students, who tend to cluster around > the largest, shiniest project suggestions. Yeah, focusing on _too big_ projects. > * Diminishing returns: Git is too mature, with little low-hanging > fruit left, making such projects harder > > * Projects are too political, progress depending on non-technical > arguments > > * Our mentors suck on various axes, notably not supporting students > enough in things that matter: > - smooth interaction with community > - ensure fast iteration/short cycles > - navigating the code base Yeah, "fast iteration/short cycles" means submitting the work early and often _to the mailing list_. One of the thing we learned too is that focusing on selecting the "best" students didn't really worked. What worked was selecting students who have already contributed patches, but unfortunately there are not many potential students who have already contributed. > Further steps > ============= > > * Discuss :-) > > And then apply this hard-won knowledge systematically. In > particular I think it wouldn't hurt to keep the project proposals > out of this thread until we have agreed on goals/standards to > measure them against. Based on the above, what about the following: 1) Advertise early and widely that we will very strongly favor students who have already contributed and that we can help them contribute long before their application process starts. Maybe we could even have a pre GSoC application process for potential students. 2) Advertise that we will really favor small projects over big/shiny ones. 3) Come up with a list of criteria like the following to measure student/application: - has the student already contributed much: 0-30 points: 0 means no contribution to any open source project, 5 means some contribution to another open source project, 20 means long time Git contributor - what is the size of the project: 0-10 points: 0 means big project (one month or more for a regular contributor) 10 means small project (one week for a regular contributor) - does the student appear willing to act on advice: 0-5 points - does the student appear to have the necessary skills: 0-5 points - does the proposal look good: 0-5 points > * Gather a list of potential mentors. I would be happy to mentor next year. Thanks, Christian. -- 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
