I would like to suggest that folks consider working on git itself. The git mailing list is very friendly and supportive and you will be making a valuable contribution to the git community. You'll also have an opportunity to brush up your C skills with guidance from some excellent C hackers.
If you aren't a C coder, you can help to improve the documentation (really, just pick a man page, there are many that can use improving). Or, look at it as an opportunity to learn C -- some parts of git are quite advanced, but there's also lots of areas that are easy to work on.
See the git wiki for some areas that can use love:
git-fetch - Download objects and refs from another repository
git-push - Update remote refs along with associated objects
Now, I haven't been a git newbie in ages, but I imagine a beginner asking "what is this objects and refs about?" How about:
git-fetch - Download changes from another repository
git-push - Upload changes to another repository
(Warning: there will be lots of back-and-forth on the mailing list about doc changes. Old timers tend to want the man pages to be technically correct, even though I think this makes the documentation harder on beginners. I suppose the argument is that the man pages are reference type documentation, but I still think there's lots of room for improvement.)
Twitter previously used some stock bird art, but the logo was just the bubble letters. Now they have an original bird logo. But 3rd party Twitter stuff can use arbitrary bird art, or maybe the old stock one since it's unclear who owns it.
I think a good solution would be a new open license logo, like the Minefield logo as opposed to the restricted Firefox logo.
I love the idea. A couple of months ago I created gistcube, It was a weekend project to learn a bit about Mongodb and Sinatra. Gistcube is a way to discover interesting gist in github. You can vote up, add to favorites, tag gists, and alos sign up to interesting/tags gist using rss.
I really hate the global web proxy at my university (RWTH Aachen).
(1, MALWARE, Phishing, Domain has unusually high traffic volume for a very recent registration. Identified as a phishing or spam-related site., BLOCK-MALWARE, 0x0b216460, 1296449561.941, QAAAAQAAAAAAAAAAG/8ACP8AAAD/AAAAAAAAAAAAAAA=, http://githacking.com/)
I like the business model, but what prevents someone from looking at a developer's solution and incorporating it without paying the developer? Say the company is charged when they use the patching mechanism to bring developer's work into their product. What would stop them from simply going around this mechanism and just copy and paste the solution into their own repository?
Also is the developer responsible for fixing bugs in their solution? Can a developer exploit the process by submitting buggy code they'll be paid extra to fix? Can a developer be required to fix bugs in their solution?
If a company can't inspect code before they pay they can't be certain it's relatively bug free, if they can inspect the code they could use it without paying for it easily.
I think it's a great idea. Our company has various projects on github that could use a second pair of eyes other than our engineers. We wouldn't mind putting a bounty on it if someone were to commit a python library or two.
The paid platform will be a bit more involved to get working, for sure. Right now we're focusing on getting this useful for open source projects to find collaborators then we'll worry about making it useful for companies.
that page is purdy but it really should explain what it's about. what's the plan. all i can tell is that it involves Git and they want an email. to be more specific: what is it beyond what we already have today with something like GitHub?
For developers, we're about connecting them to projects that they'll likely be interested in contributing to; these projects may or may not be most forked or trending. A lot of repository identification is word of mouth which, for those on on the outer rings of the open source community, may be lacking. We want to change that.
For maintainers, we're about finding developers to fill the needs of their projects. Open sourcing is step one, promoting and keeping traction can be tough. We want to arm maintainers with more to help accomplish this.
For businesses that rely on the open source code contributors and maintainers support, we want to provide a platform that they can leverage whether it's support or issue resolution. Businesses win because they get fixes, for example. Maintainers and contributors win being rewarded for their efforts.
We have several other ideas we're exploring; lot's more to come.
Social is a little misleading. It's more about connecting developers to projects. For contributors, it's about finding projects that would be of interest to them. For maintainers, it's about finding developers to fill the needs of their projects.
This is neat, i intend to use it. I've been thinking recently it would be great if there was "OkCupid for code" and once you have enough data to predict good matches for people <=> projects you could do some interesting things.