GitHub already made this easier, but I feel like they just aren't pushing it in front of everyone early enough. They added support for the CONTRIBUTING/CONTRIBUTING.md file[1], but it is only displayed when opening up an issue or pull request. I think all they would really need to do is advertise projects which have a properly set up file while browsing, similar to how README files are already displayed. If a person wants to contribute, telling them how to contribute only after opening up an issue/PR is a bit late, no?
It seems like contriubtion guidelines aren't necessarily what the author is pushing. AFIK, this wouldn't help new developers get up to speed with the code base.
One thing I've found is that there is a lot of independence on GitHub. My immediate assumption if I see a project public project on GitHub is that the owner is saying "I'm ready and willing to accept help." The challenge of not knowing where to start is something different.
A lot of projects can be complicated (D3.js comes to mind). If you don't have a really good grasp on a few very key disciplines in math then honestly, before you contribute to D3, you should brush up on that. The system is self regulating in a sense where you have to know enough about the subject to contribute.
Maybe, there should be a section that people add to their README.md that explain what you need to know before you start digging into a project along with a project goal. I know that for my project[1], I want to create an authoritative .gitignore database, but I'm not really clear on that being my goal nor am I clear on where to add your new files. All of the contributors to my repo have figured it out though without me really telling them anything.
> All of the contributors to my repo have figured it out though without me really telling them anything.
It is also true that everyone who didn't figure it out, did not contribute. This is a much bigger problem. Not specific to your project, more of an issue at large, but saying that '100% of people who contributed figured out how to contribute' isn't a grate benchmark for success.
It's not a benchmark for success and I'm going to make a change tomorrow to my repo that lets other know what they can do to contribute. What I don't think is good is people that don't understand what's going on making pull requests when they don't see the vision of the project. So far I have not gotten any of those which tells me that everyone who is making pull requests understands what the point of gitignore.io is.
http://openhatch.org/ tries to solve exactly this problem: they're working to bring in more people into OSS, so they pay special attention to make it easy for new programmers (or even non-programmers) to find a good match and start contributing.
On top of just using the site, you could also chat with them about the problem in general - they're very open and friendly.
That actually looks pretty promising - the biggest thing that I've seen that drives usage on GitHub is README badges.
It sounds silly, right? Just a badge? But look at Travis, Code Climate, Gemnasium, etc. You see those badges on a project and eventually you start adding them to your own projects and they spread across a site filled with highly qualified leads (developers for your developer-centric service).
The first code review tool to make a badge and get a handful of Ruby projects to use it is going to really take off.
"A waffle is like a pancake with a syrup trap." - Mitch Hedburg
Props to them for the Hedburg quote. Was listening to that CD of his stand up (although, those jokes were for the CD, and maybe he'd done it elsewhere as well) just the other day.
So github is turning into the old Source forge then? There was a page on there years ago where projects could advertise who are they looking for. I found a couple of projects that needed packagers this way and learned more about maintenance. I think it's a really good idea.
GitHub could probably suggest projects automatically based on recent activity. ie find projects which have a good flow of recent activity and have accepted external pull requests, but aren't intimidatingly large.
Funny how this is on the front page today ;) just yesterday I wrote a post about how it would be a good idea to quantify the importance of open issues, to encourage contributions. Check it out here: http://dennybritz.com/blog/2013/08/04/github-api-issue-analy...
If someone wants to work on this together just shoot me a message!
I strongly disagree. If you're a new developer looking to work on something, anything, completely indiscriminately then you're probably not ready to work on anything. The time required to contribute even on minimal issues is not insignificant. It requires learning at the very least what the project is, does, and moreover should do.
I think the phase of "what should I work on?" is a fledging phase of developer development that one quickly overcomes and then becomes burdened by the vast opportunities that exist. I think erecting a sign/button/webpage that says, WORK ON $THIS, will do nothing to help it because the would-be contributor may have no interest in the project. Also, it may inhibit the formation of their taste. One must develop enough of an interest in and taste for software that they want to change some aspect of it; that's when an opportunity to contribute something valuable presents itself: "This would be better if..."
24 Pull Requests[0] was launched during Christmastime, and was a great resource for finding projects in need and posting my own. I only wish it were available year-round. Anyone want to pick up the torch here?
Personally I'd be more able to help out with a lot of projects from a documentation / training / support POV, github isnt really designed for that kind of thing, but it would be awesome if there was some kind of profile page where people could contribute to FAQs, How Tos, etc
I've found that the best way to contribute to most open source projects is to try to use them, and then fix whatever shortcomings become obvious. This only works for things that are fairly new, and have obvious problems, but those can be a lot of fun.
This! You must become a user before you can become a contributor. Then the vacuous "What project can I contribute to?" question becomes more intelligible, "What software should I use?" That depends. What do you want to do?
This is a fantastic idea. There are some projects I'd like to help with, but issues that crop up often require way more in depth knowledge. Other areas I can't help but feel I'd need the authors permission to really mess with a section. Am I allowed to clean this up?
Saying to the repo owner "I'm ready to work, met something out to me" would be great!
[1] https://github.com/blog/1184-contributing-guidelines