Looks like Monday is the preferred day for our Tweetchat, so let’s chat on Monday, June 1, at 5:00pm Pacific/8:00pm Eastern. We still need a hashtag, as #1GenLibProfs doesn’t exactly sing. Suggestions welcome!
There is absolutely nothing in this world like the feeling of sucking at something and then improving at it.
Ta-Nehisi Coates on the hard work of getting better at something. I’d do well to remember this whenever I want to quit learning Ruby.
I’m on my third go-around with Skillcrush’s Ruby Blueprint, and once again I’ve become stuck on class variables, class methods, and attribute accessors. I’m comfortable with being bad at this, but I’m worried that the “getting better” part that Coates alludes to will always be just out of reach.
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 good will about your product is a key component of your project’s success.
Realize that you are your own solution. You have what you need to look clearly; to hear and to heal. Anxiety is a message born within you, speaking to you through you, and therefore it’s within you to heal.
I’ll need to keep this in mind over the next few months. Thanks, Tiny Buddha.
“Survey says…!” (I’ve just dated myself with that reference, haven’t I?
It looks like most of you thought a weekly tweet chat was the best way to stay in touch, so let’s get one started! First, we’ll need to settle on a day of the week. Because #libchat and #critlib both take place on Tuesday and I don’t want to compete for attention, I think we should hold this chat on a different day of the week. Also, if you have an idea for the hashtag we should use, leave it in the comments below.