As participant in GSoC 2012 I'll mostly respond to this from a student point of view. Generally I had a great learning experience with my project. It was a great introduction into how the Git project and open source projects in general work and certainly lowered the barrier to start contributing to Git. I was and still am grateful for this experience. Even though my contributions after the GSoC were very small, I wouldn't have contributed those patches if I hadn't participated in GSoC before. That probably doesn't (yet) make up for the work invested in me, but I certainly hope it will down the line. Thomas Rast <tr@xxxxxxxxxxxxx> writes: > [Unfortunately libgit2 no longer has a mailing list. I put an arbitrary > group of libgit2 contributors in the Cc list.] > > > 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. > > > GSoC 2007-2012 > ============== > > Data presented in [2] shows that roughly half of the projects resulted > in merged code, and roughly half of the students remained with the Git > community significantly after the end of GSoC. (The sets aren't > exactly the same.) > > A feeling expressed in [1], [2] and elsewhere is that this is not > enough value for money and effort. We should therefore discuss how to > improve. > > Note that everyone seems to agree that libgit2 had a much better run > in GSoC than core git. There seems to be less agreement on what > exactly they do differently, though. > > 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. This was mostly why my project wasn't merged, imo. More complicated projects generally sound more interesting (to me at least), so I directly went for one of the more complicated ones. There were a few warnings that this might be too complicated along the application process, but without real previous knowledge of the code base I overestimated myself and underestimated the project and chose to ignore all of that. As some of you may know I'm still working on the project, but my time is limited so it will take a while for it to bring it to inclusion shape, if it every will be merged. > * 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 Especially at first I was reluctant to use the mailing list for discussions and used the #git-devel irc channel a lot for that. While I felt these conversations were very fruitful, it would probably have been good to send at least a summary email to the list after those conversations. > - ensure fast iteration/short cycles I think that was quite hard to do with my project, as it was impossible to split up. I think this would not only help community interaction, but would be great for the student too, getting the satisfaction from getting patches merged early. > - navigating the code base This was the least of my problems, I got good pointers on where to start from Thomas and others on the irc channel, and help was always available to me, whenever I needed it. > * Scope creep: projects tend to get blocked on some bigger > refactoring/restructuring task that was not in the original proposal > > > Ideas and Suggestions > ===================== > > These are mostly from [2]. There were some suggestions that we learn > from Matthieu Moy's very successful student projects (eg. [4]). > > * View GSoC much more as a lot of work than free labor > > * Break projects into smaller, easier tasks > - They should individually be simple, quick things if the mentor did > them. > - Should be parallelizable so students don't have to block on reviews. > > * Mentoring improvements: > - Always have a co-mentor > - Focus on social aspects (who to Cc, etc.) > - Nominate separate "review mentors" to ensure fast review cycles > > * Define explicit criteria > - what we want to do > - how we judge code and social interactions > - when to fail the students > > * Have students review some patches > > > 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. > > * Does libgit2 want to remain under the Git umbrella, or participate > on its own? > > * Figure out the wiki situation. In previous years the project > proposals and other important information were hosted at k.org [5] and > github wikis [6]. Other options were floated, such as an official > wiki hosted by github. (This is somewhat of a contentious issue that > spans beyond GSoC.) > > * Find an org admin and backup. In previous years Shawn and Peff did > this. Would you do it again? > > * Gather a list of potential mentors. > > > > [1] http://thread.gmane.org/gmane.comp.version-control.git/216485 > [2] http://www.youtube.com/watch?v=XP4CxUkBPSQ; > [3] http://googleblog.blogspot.ch/2013/10/50-million-lines-of-code-and-counting.html > [4] http://thread.gmane.org/gmane.comp.version-control.git/221159 > [5] https://git.wiki.kernel.org/index.php/SoC2011Projects > similarly for previous years > [6] https://github.com/peff/git/wiki/SoC-2012-Ideas > https://github.com/trast/git/wiki/SoC-2013-Ideas > > -- > Thomas Rast > tr@xxxxxxxxxxxxx -- 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