Re: Google Summer of Code 2013 (GSoC13)

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Feb 18, 2013, 23:03 UTC
Message-ID: <20130218230303.GC4022@elie.Belkin>
In-Reply-To: <20130218205532.GB27308@sigill.intra.peff.net>

Jeff King wrote:

> On Mon, Feb 18, 2013 at 11:34:24AM -0800, Jonathan Nieder wrote:

Show 18 quoted lines

>> Some potential projects (unfiltered --- please take them with a grain
>> of salt):
>> [...]
>>  - collaborative notes editing: fix the default notes refspec,
>>    make sure the "notes pull" workflow works well and is documented
>>    well, offer an easy way to hide private notes after the fact
>>    without disrupting public history
>
> I know you said a grain of salt, so please don't feel like I'm beating
> up on your idea. I'm picking this one because I think it has some
> characteristics of projects that have not gone well in the past, so it's
> a good illustrative example.
>
> IMHO, this is the type of project that is likely to fail, because most
> of the work is not technical at all, but political. Changing the default
> refspecs is a few lines of code. But the hard part is figuring out where
> they should go, the implications of doing so, and how people are going
> to react.

I think I agree, if by "likely to fail" you mean "easy to underestimate the difficulty of". I actually think it would be a pretty good summer student project, for a few related reasons:

 * Years of evidence show it is a hard problem.  It would be a good
   notch in the belt of whoever takes the project on.

 * It does not require a deep understanding of git internals.  A good
   familiarity with the git user interface, on the other hand, would
   be essential, but I hope that is becoming more common among
   students these days.

 * It requires good taste and design sense, which are something it
   would be nice to cultivate and encourage.

 * The change is necessary and the satisfaction of helping a student
   through the process might be enough to finally get it done.

 * If an amazing candidate finishes the "make collaboration possible"
   task early, there's plenty of valuable, interesting, and technically
   complicated follow-on work regarding the related "share some notes
   while hiding others" to fill the rest of the summer.

The code change for the most basic subset of "make collaboration possible" would presumably be a changed refspec, some documentation, and some tests. On top of that there is presumably some automagic incorporation of upstream notes to be cooked into "git pull". Some better conflict-resolution magic. Example scripts to generate notes. Support for the format-patch / am workflow. gitweb support for showing notes.

It's a good example of when it's useful to not be afraid of failing to please everybody and just get something done.

I also can't think of any examples of such technically straightforward student projects being tried before.

Jonathan