Jeff King wrote: > On Mon, Feb 18, 2013 at 11:34:24AM -0800, Jonathan Nieder wrote: >> 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 -- 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