DRAFT: Want to make meetings better? Qworky is recruiting for a diverse open source project!

Update, December 17: Thanks to all for the excellent feedback, here and in email!

I’ll be splitting this into two posts, which will appear on the Qworky blog

Thanks also to those who expressed interest … if you’d like to get involved, stay tuned — or get in touch via the contact information at the bottom of the post.

As a company we view diversity as a vital ingredient to sustained business success. We value unique perspectives and traditionally under-represented viewpoints in the software design process. We welcome collaborators from every walk of life. We welcome people of any gender identity and expression, race, ethnicity, sexual orientation, experience level, discipline, educational background, culture, and political opinion.

— Qworky’s draft diversity statement
In early January, we’re going to be kicking off an open-source project to build a key component of the Qworky Meetings V1.0 product. How to attract a diverse team? Kirrily Robert’s outstanding Standing out in a crowd OSCON keynote and earlier Dispatches from the Revolution look at two highly-diverse open-source projects, and provide some excellent suggestions for this situation. For example, Dreamwidth started out by posting a clear diversity statement. Hey, we should do that!

And when Organization for Transformative Works’ Archive Of Our Own started up they resisted the trap of focusing primarily on experienced programmers. Instead they invited everybody who was interested and had a passion for getting involved, chose a language that was accessible to non-programmers, and put the effort into organizing and documenting the project well enough that newcomers could easily see what was going on and where they could help. Hey, we should do that too! So we spent some time at this Saturday’s engineering meeting discussing what else we could do to make things easily accessible, and how we’ll reach out.

A common theme in these examples, and one that Selena Marie Deckelmann also touches on in What works? Getting more women involved in open source, is to make sure that people who might be interested in the project know they’re invited. One of the great things about working on software for meetings is that it’s a topic almost everybody relates to — these days, even high school and college students have to deal with action items. So do small businesspeople, moms, teachers, activists, consultants, administrative assistants, system administrators, customer support experts, designers, programmers, testers, etc. etc. etc. … So please, consider yourselves invited!

It’s a great chance to get involved at the early stages of an open-source project with world-class software engineering that’s truly committed to diversity.* And if we can make meetings better, we’ll make all of our lives easier and earn the world’s gratitude. Talk about upside!

If you’d like to get involved, please join us at our first planning meeting early next year — check back here for details. If you’re so eager (or so bored over the holidays) that you can’t wait until then, please get in touch with us. We’re @qworky on Twitter and I’m jon@qworky.net — or just leave a note here in the comments.

If you know anybody else who might be interested, please pass the word. And if you have any suggestions for how we should be reaching out, please let us know!

On Twitter, @skud pointed to the Geek Feminism Wiki’s page on Recruiting women, which begins with the excellent suggestion of starting by thinking about why we want to recruit women. Wow, where to start. For one thing, since software tends to reflect the biases of the people who create it, a diverse team will create software that’s better for more people. From a team dynamics perspective, projects that skew heavily male tend to be far less collaborative. From a company culture perspective, our attention to diversity is a key part of who we are. The list goes on …

There are plenty of other great suggestions on the Geek Feminism Wiki page as well. Thanks for the pointer, Skud!

Ditto Denzil and Allyson. I like that you did your homework and asked yourselves Why. Many companies don’t go beyond tokenism. This is a *business* issue. As in more business: A well managed, collaborative development process makes for a better product. A better product is more likely to succeed in the marketplace. Success in the marketplace validates ideas. Everybody wins.

Kudos, and I look forward to following your progress in the coming months!

One thing I would add is something about disabilities. Formats of meetings, on-line forums, etc. can make it either easier or harder for people with sight, mobility, and hearing limitations to participate in, and your software will end up being usable by more people if you start thinking about accessibility of the project and the software up front.

PS from Jon: this came in via email, and is posted by pemission — the sender preferred to remain anonymous

Excellent point about the importance of addressing accessibility — for our team, and for our product. Our requirements for our V1.0 web product include accessibility, and we should probably mention it as well in our diversity statement.

This, by the way, is yet another thing that Dreamwidth got right; Kirrily quotes their statement:

We think accessibility for people with disabilities is a priority, not an afterthought. We think neurodiversity is a feature, not a bug.

Put women in control. If you do nothing else for the women (and men) who support you, make is EASY for them to connect with you and your work. De-clutter your website. Offer lots of opportunities to get involved. Suggest text that they can repurpose and share with friends. In short, make your cause about her, not you!

There’s been a lot of email discussion as well; I’ll try to collect as much as possible here.

Somebody forwarded on some bullet points from Kirrily, summarizing her recommendations:

* recruit diversity as early as possible
* have a code of conduct or diversity statement, and stand behind it
* set up tools to assist newcomers and lower the barriers to entry
* be transparent about how your project works
* don’t stare or treat women as if they were unicorns
* value all contributions
* call people out for sexist behaviour
* pay attention to the little things that might discourage people

I’d have to say that we’re currently very weak on the “lowering the barriers to entry” — I was just writing the documentation about how to get up and going in the Qworky development environment and … um … let’s just say that “friendly” and “simple” were not the words that leapt to mind. This is clearly something we’ll really need to concentrate on.

Thanks Jon for this post. We’ve talked about the importance and value of diversity from the outset when we decided to work together. This is a great time to review our thinking and continue the discussions in a public forum.

I found the wiki that came in from @skud particularly thought provoking- and it appears thats continued on both the comments here and in email.