Maybe there should be a standard tag? Similiar to versioning http://semver.org/
http://fedoraproject.org/join-fedora is pretty much the best "How to Contribute" example I've seen.
Gives people who come to your repo a good idea of the progress of various issues, I've found it to be somewhat useful
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.
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.
The site and concept look pretty cool too.
- "getting started as a developer"
- "this is how this works"
- "new developers should start reading here, browse here, and ignore this until later"
style info. I think this is what the AP was bringing up. And it is what was being discussed in the blog post. Lowering the barrier to entry.
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.
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.
If you have a strong grasp of the project, you already understand pull requests. The best thing newbies can do is expand and clarify the docs.
On top of just using the site, you could also chat with them about the problem in general - they're very open and friendly.
If someone wants to work on this together just shoot me a message!
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..."
Saying to the repo owner "I'm ready to work, met something out to me" would be great!
I've been using Ninja IDE and going to start contributing to it.
