Disclaimer
Not trying to blame anyone here. I‘m just taking an idea I‘ve read and spinning it further:
Intro
A lot of people use free open source software (foss), Linux being one of them. But a lot less actually help make this software. If I ask them why, they always say „I don’t have the coding skills!“.
Maybe its worth pointing out that you don‘t need them. In a lot of cases it’s better to not have any so you can see stuff with a „consumer view“.
In that situation you can file issues on github and similar places. You can write descriptions that non technical people can understand. You can help translate and so on, all depending on your skills.
Other reasons?
I‘d really like to know so the foss community can talk about making it worthwile for non coders to participate.
Tried submitting a relatively simple change to the Ansible code base once. Added an option to the telnet module to support different ports. Submitted a pull request. Was told I needed to change and update the documentation. Didn’t know how to do that, and I didn’t get any guidance, so I abandoned the pull request. Kept on using my own hack until someone else added the option.
Make contributing easy, and more people will contribute.
I absolutely agree. This needs to get a lot better. But talking about this will facilitate change. Thanks for taking part.
Pretty much this. I had a similar experience on a different project. If I ever submit a patch again, I’ll make sure to run it by the maintainers before I start coding.
Maybe it would help to have some kind of boilerplate language and framework for contributing that other projects can make use of.
Solution should not be technical.
CONTRIBUTING.md should be very simple to follow and have all the steps necessary to submit a successful contribution.
Have a section in there for first time contributors. Link to a YouTube video outlining the basics if need be. Explain the process from the very beginning. If you want fresh talent to contribute, educate them on the right way to do so. (Perhaps this is an opportunity for boilerplate language. However, best current practice may change over time.)
Be pleasant to and patient with contributors who fall short. They may never have contributed anything before. In that case, you are an ambassador not just for your project but for all open source projects. Don’t be a jackass who drives away talent just because they didn’t do something exactly perfect.