I attended Una Kravets' OSCON talk, "Open Source Design: A Love Story," after interviewing her recently.
To begin, Kravets reminded us that we all gathered at OSCON to be inspired to innovate. She also noted (as we all know) that the technology sector is not as diverse as it should be—and that this problem is particularly bad in the open source world. And when Kravets talks about diversity, she is isn't referencing gender and race, but a variety of skill sets as well.
Kravets showed us a report she found. It reviewed 23,493 GitHub projects and found that 75.3% had no gender diversity at all. This brought Kravets to the following quote from Malcolm Gladwell: "The world that we could have is much richer than the world we've settled for."
The world we have settled for is broken, Kravets said. We love open source and open source communities—but it's broken. But Kravets suggested we have the power to make it better.
To explain how, Kravets shared with us the story of the road. This story has three characters: the designer, the developer, and the business person.
The business person says, "We need to get from Point A to Point B," and he tells this to the developer. The developer says, "Good idea, let's build it with this new technology." The two then approach the designer, and she says, "Let's build the road on the coast so that people can enjoy the ride."
The moral of the story? Diversity creates better projects. So, why aren't designers participating in open source?
Kravets answered this question in two ways:
- Because many designers harbor the idea that they have to be paid for their work. We must fight against the idea that it's bad to do work for free.
- The second reason is the 'museum effect'—people are scared to touch things and break things.
Kravets then proposed two ways to encourage designers to participate in open source projects.
Encourage a more open design/development workflow
Don't design alone, Kravets said. Design in the open so everyone gathers feedback along the way. If you let a designer go off to work on her own, when she returns with a final product she might be frustrated by feedback and requests for change. Instead, ask the designer to work in the open as part of the team. (Git can be a starting point, Kravets said.)
Kravets created gulp-starter-env on GitHub in order to give designers the tools they might need to do their work. The next key to making this work is to share excitement. So when Kravets's team of designers figured out how to push to git, she celebrated those wins with them. Telling a designer she must learn to code will make her defensive, whereas sharing your excitement about code with her will make her curious. This is what was want to do, Kravets explained.
Foster design participation
With Kravets's team, this was easy—because they were already using GitHub and excited about it. But how do we do this with others? For this, Kravets gave us the CARE acronym.
Communication
This is as simple as letting people know that we want their help. In GitHub, we can label things "design" in order to show designers the issues they can work on.
We can also create project boards. These can include all the information about ways designers can get involved, and list our design standards (such as colors, style guides, etc.).
Using GitHub, we can create a "checklist" that functions as a visual way to get designers involved in our projects and helps them visualize their progress.
And finally: Use a lot of images! Designers are visual, and these images help people see how things are supposed to work.
Accessibility
Ask yourself: "Can people get started with my project?" Always be sure to have "getting started" documentation. "Readmes" on git are notoriously useless, so make yours more accessible and helpful. Assume the person reading it has no coding experience. Create a lexicon to help new participants. While devleoping, we all use jargon, but newbies don't understand all of it.
Kravets did an informal study and found that projects with websites, documentation, and demo exhibited more diversity. And projects with more diversity were more likely to have documentation, websites and demos. So documentation increases diversity, and diversity increases documentation. I found this interesting, as a female documentation manager on a project (Koha) that didn't have a complete manual before I started participating.
Respect
Design builds community. We can see this with logos. A logo creates a visual asset around which people can gather. Kravets showed us a GitHub thread that featured a community trying to design a logo together—but things went horrible wrong and started to attract trolls. Respect means more than just needed to attract designers; it's needed to keep open source projects going.
Empathy
Open source is about people! We should treat contributors as we treat our families. There is an argument culture in our communities, where it's more important to be technically correct instead of listening to ideas and working as a team.
To conclude her talk, Kravets suggested we set up feedback guidelines for our communities:
- Ask don't tell: "Why did you decide to..."
- Be specific: "When you are calling the..."
- Explain yourself: "Check out this blog post..."
- Offer solutions: "Maybe try..."
- Avoid hyperbole: Avoid "Never," "No," and "Don't"
- Use emojis: Because they make everything better
Series
This article is part of the OSCON Series for OSCON 2015. OSCON is everything open source—the full stack, with all of the languages, tools, frameworks, and best practices that you use in your work every day. OSCON 2015 will be held July 20-24 in Portland, Oregon.
4 Comments