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. And it's intimately tied to how we have considered refactoring the default ref namespaces, which is a messy discussion with a lot of different options (and implications, and backwards compatibility issues, etc). Plans need to be laid for deprecating old things, and handling the transition to the new thing. Lines need to be drawn about what is in the project and what isn't. Bringing a project like that to completion is going to involve a lot of community involvement. And that's the thing students are historically the worst at it. I think it's _also_ the most valuable thing they can learn. But I think it doesn't make for a very gentle introduction to open source. Again, just my two cents. I don't want to dissuade anybody from this project in particular, or this style of project. I'm more trying to bring up discussion on how and why projects fail. -Peff -- 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