
Git Project Hell - davidw
http://djberg96.livejournal.com/178299.html
======
lusis
You want the answer? Start adding some of those people to the main project. If
they're writing the proper tests and the code is solid, add them. If they
botch a release, remove them and roll back.

There are two scenarios:

1) You aren't responding to pull requests in a timely fashion 2) Your original
code isn't meeting the needs of the users

If there are that many active forks, consider inviting the most active
contributers to IRC and finding out why they aren't making pull requests. If
they are and you aren't responding then the blame lies soley with the master
repo maintainer.

~~~
davidw
The answer is a proper, centralized project, with a mailing list for
communication and coordination, and for the forkers to at least make a stab at
getting involved.

If that's not working, one of the forkers should fork the _project_ , not just
the code.

Projects are things involving people, when all is said and done. Community and
communication are what make an open source project work, not the ability to
bounce code around with push/pull requests. Those things help, because they're
more efficient than mailing patches around, but people have been doing this
stuff for a while without github...

~~~
lusis
Good point about the mailing list. At this point though, it seems that just
finding a way to deal with the multitude of forkers is the biggest issue. That
might be a mailing list or it might be a shoutout on github asking for
information.

I'm not too keen on a big structure off the bat when you don't know what the
reason for the forking is. Then again with google groups it's really not that
big of an issue to set one up.

And I'm fully aware that people have done this for the longest time without
github but right now, github is where the "community" lives. It would be
unwise to go shunting the community around to some new thing without first
establishing what the community is.

