In a previous post I called out Hoodie as an example of not-terribly-clear instructions on how to contribute to their project, so I was happy to discover a post that clearly states how you can get involved in some of their open source projects. Go read Contributing to Hoodie and get started!
Listen, I won’t bore you by telling you that you have to learn to code. If developing this skill makes sense for the kind of work you need to do (or would like to move into), then by all means, spend the time and money on learning. But there are other ways to contribute to software development projects, and one of those ways is by helping write documentation.
I’ve spent a few months looking around for a software project I could contribute to, but for the most part I’ve felt stymied. Either I didn’t know enough about the project to know where to jump in or the kinds of help the project needed were far beyond my meagre skills. If these DuckDuckGo search results are any indication, other folks have wondered how to get involved as well.
Even projects that are hugely welcoming (hi, hood.ie) have left me unsure about where my talents were best suited because the descriptions were written in such a way that you had to have some advance experience with or knowledge about the project to know where to jump in.
If you want to make sure that your project is welcoming to people of all skillets, makes sure your requests for help are written as clearly as possible.
I’ve spent the better part of this weekend contributing to the Exercism project. It’s a library of exercises that supports students learning to code by giving them practice problems and helpful, constructive feedback.
I don’t remember how I came across the project, but Katrina Owen wrote her request for help so clearly and succinctly that I immediately jumped in.
Many column inches and bytes of data have been spent telling us how software development/open source projects need to diversify. This point isn’t up for discussion. What still needs to be addressed is how companies can build their communities so that anyone with access to a computer and basic literacy skills can feel confident enough to contribute to their project.
It seems that many companies err on the side of difficulty/obfuscation when soliciting help. Maybe this is a way to weed out people who they think lack dedication, or maybe they’re afraid of talking down to people. Those are valid concerns. Computer use has become so ubiquitous that not everyone who sits in front of a computer is a computer scientist, yet nearly all users could make valid contributions to your open source projects if given the chance. Creating tasks at all levels is one way of giving newcomers the chance to participate.
Here are a few things you can do to remove some of the barriers to participation:
Make your descriptions clear and unambiguous. If you need grammatical help, say “We need help with grammar in this paragraph” and highlight the paragraph in question.
Be receptive and open to questions. Really mean it when you say “ask us anything,” and make sure your responses are friendly but helpful.
Avoid using words like “basically”, “just”, or “simply” when writing instructions. These words are shorthand for “You’re too stupid/inexperienced/dumb to work with us.”
Invite users to offer feedback on an interface, whether it’s labelling for form fields or other interface elements or inviting them to comment on typography or colour schemes.
Lastly, thank your contributors and let them know they’ve done a great job. Even the smallest contributions improve your overall product. Remember that people respond well to thanks and praise, and instilling goodwill about your product is a key component of your project’s success.