you really needed someone to tell you that it's easy to contribute to open source?
It's not merely a question of needing to be told that it's easy to contribute. That's not even the right way of looking at it. The question is whether it is easy at all, and I say no. If someone told me it was easy to contribute to open source software I'd know they were either lying or delusional.
I think the thing that people often miss is that getting a patch that works is really only 50% of the process of getting a bug fix/feature merged into an Open Source project.
In a company, the hiring process is an initial crap filter (or at least is supposed to be). In an Open Source project, the filters work very differently. You won't find a lot of (community driven) projects that spend a lot of effort putting together detailed documentation about how to build a project and submit patches. That's because figuring this out is the first level filter.
The second level filter is figuring out the architecture of the project. This can be difficult in a subtle way. In a company, you can usually sit in a conference room and have someone explain to you all of the details of the project such that you have a pretty good idea of how a patch or feature should be implemented.
In most Open Source projects, you generally have to code up an initial version of the feature and then you'll attract enough eyes that you'll get the feedback about how to do the feature properly. If you're a long term contributor, you skip most of these steps and the process is fast. If you've never contributed before, it's almost certainly going to take a lot of effort.
It's all about scalability. Open Source projects significantly reward people that are self motivated and can figure processes out without a lot of hand holding because that's the type of person you need to build a successful project when there aren't any managers, program managers, or formal architects.
I think that's probably the biggest value of the proposed plan. If someone has gotten 50 patches into a major project, it says a lot more about the individuals personality and motivation than it does about their programming skills.
Absolutely not. It's because it's boring and it's time for bed now so let's do that tomorrow. Eventually it does get done, though; all the big-name open source projects have this sort of documentation available.
(And now, thanks to Github and the implicit fork-and-pull-request model, so does almost everything else. Reuse++!)
If you are getting a lot of pushback on your changes ("it's not indented right"), there is probably something else that's wrong. And sometimes, there is administrative triva to deal with.
(The other day, someone sent me a patch for ibuffer-git via a github issue. I'd prefer a pull request, but fine, whatever, easy to apply anyway. The problem is that I need to keep a list of contributers in case I decide to contribute the extension to the emacs core. This person had no contact information, so I couldn't just apply his patch. I really needed the fork-and-pull-request so that the author information would be properly recorded. Annoying for a 2 line patch, but a necessary evil. And even then, the patch is applied in my repo, it's just not pushed yet :)