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.

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to