git/list[1] front-page[2] threads[3] people[4] search[5] about
 

GSoC 2014: Summary so far, discussion starter: how to improve?

From
Thomas Rast <tr@thomasrast.ch>
Date
Oct 19, 2013, 06:09 UTC
Message-ID
<8761stx04i.fsf@linux-k42r.v.cablecom.net>

[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.
* 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
* 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@thomasrast.ch
Next: Christian Couder
Message 1 of 11 in “GSoC 2014: Summary so far, discussion starter: how to improve?”
  1. Thomas RastOct 19, 2013
  2. Christian CouderOct 19, 2013
  3. Felipe ContrerasOct 19, 2013
  4. Fredrik GustafssonOct 19, 2013
  5. Thomas RastOct 26, 2013
  6. Thomas GummererOct 20, 2013
  7. Junio C HamanoOct 22, 2013
  8. Thomas RastOct 26, 2013
  9. Thomas RastNov 21, 2013
  10. Christian CouderNov 21, 2013
  11. Jeff KingNov 21, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.