What are the problems faced by people who are starting to contribute to OSS
5 comments
There will be people reading this who have never used a Terminal, or typed at a command line, or called directories anything other than "folders".
There will be people reading this who have never installed anything that wasn't from an App Store.
There will be people reading this who have never heard of source control, branches, repos, or any of the other jargon in your document.
I think the number two thing project maintainers need to do is to stop making assumptions about the background and experience level of their potential contributors; or, if they do, to admit and outline them.
I write more about this here: http://opendesign.foundation/articles/import-designers/
There will be people reading this who have never installed anything that wasn't from an App Store.
There will be people reading this who have never heard of source control, branches, repos, or any of the other jargon in your document.
I think the number two thing project maintainers need to do is to stop making assumptions about the background and experience level of their potential contributors; or, if they do, to admit and outline them.
I write more about this here: http://opendesign.foundation/articles/import-designers/
Someone described by those first 3 things probably couldn't do much on an OS project anyway.
That's the another problem potential contributors face: Assumptions that because someone is not technical, they can't meaningfully contribute to a project. Dismissal of plain users feedback because "they don't know what they are talking about".
Unless you're creating OSS tools for e.g. developers, your final users are probably not as technical as yourself - so you might want to hear feedback from people that actually has to use your tool.
(Sorry, this is not really directed at you and I'm not picking on you, I don't know you at all! :) Your comment just reminded me of what I describe above)
Unless you're creating OSS tools for e.g. developers, your final users are probably not as technical as yourself - so you might want to hear feedback from people that actually has to use your tool.
(Sorry, this is not really directed at you and I'm not picking on you, I don't know you at all! :) Your comment just reminded me of what I describe above)
Agree with @flukus. I didn't put anything about pre-requisites because I didn't want to drive anyone away. Anybody seeing these things for the first time can just google it and learn right?
Everyone has to start some place.
If this is intended for noobs, I suggest cleaning up your example fork/branch/push/pull request.
You have the reader create a branch called add-your-name, then push that to the server. Only the next example for the pull request talks about a branch called fix-readme. This will confuse novices.
You have the reader create a branch called add-your-name, then push that to the server. Only the next example for the pull request talks about a branch called fix-readme. This will confuse novices.
Here's a link to what I've started
https://github.com/Roshanjossey/first-contributions
Seems very specific to git/github, which are popular here on HN but there is a great deal more variety out there.
I'd suggest something that doesn't deal in specific technologies but more general principles.
I'd suggest something that doesn't deal in specific technologies but more general principles.
Thank you for the insight. Will checkout other tools as well.
I'd point to a few examples of pull requests which were merged into OSS projects already and explained what authors generally went through.
Check out this:
http://openhatch.org/
http://openhatch.org/
I've started out with a simple readme file which explains the basic git and github workflow. Please give me feedback