It is a peculiar time to be a black American. Maybe there has always been tension in this relationship; maybe in the past I’ve been more willing to live within that tension, to use it to test my own limits of what I can endure. Those limits were pulverized into powder this week.
America is in distress. I am in distress. And I’m feeling like we are all beyond saving.
I work in a scent-light workplace, so I try to be conscious of wearing heavily perfumed grooming products. This morning it couldn’t be helped because I was out of my usual hair gunk and had to use Oyin Handmade Burnt Sugar Pomade on my hair.
A guy who works in IT got on the elevator and remarked “It smells like maple fudge in here.” I pointed to my head and sheepishly apologized. “No, it smells good. Can I lick your head?”
(I originally posted this to Facebook, but the response I got there convinced me to post it here.)
Dear Active Transportation Advocates & Advocacy Groups:
Until very recently, I rode a bike everywhere.
I was still fat.
I’m not alone. Oh sure, there aren’t many of us in Vancouver, but there are in other cities.
If you want to convince more atypical people to adopt active transportation as a lifestyle choice, STOP DEMONIZING FAT PEOPLE and stop using the “obesity” scare word. It makes you look like smug a-holes.
Here are a few free tips on how you can get more people on bicycles:
Talk about how much fun it is to ride a bike.
Tell them that riding a bike makes you feel like a kid again.
If they’re slightly libertarian, tell them how riding a bike makes you feel like you’re getting over on society (which I personally enjoy).
Tying desired cycling improvement to behavioral and “health” outcomes is a surefire way to keep people off their bikes, particularly if they’re already feeling beaten up by the fitness/health industry.
A Fat Person on a Vespa (for now, until she can ride her bike again).
The inaugural First Generation Library Professionals chat went very well last night – much better than I expected. The biggest takeaway for me is that there is definitely a need among those of us who fall into this group to network and discuss issues around class, access, and navigating professional responsibilities. What I didn’t expect were the heartbreaking stories of how entering into the professional class created distance — and in some cases, resentment — from family members.
Other chats are forthcoming. If you have suggestions for chat themes, leave them below in the comments, or connect with me via twitter.
Many thanks to Abby for creating the Storify archive of last night’s chat.
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!
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 goodwill about your product is a key component of your project’s success.