Stating the Obvious?

One thing I have learned while attending events around the world is how to at least say four things in the local language: "hello, goodbye, please, and thank you." It's not much, and I realize its yet-another sign of U.S. cultural centrism that I don't know more languages than English and some German, but I figure if you're going to visit someone's home, the least you could do as a good guest is try to be polite.

Language barriers are not the only thing that can create difficulties communicating, particularly within communities. Personalities, methodologies, and even the most basic goals for a community can put community members at odds.

That last might seem a bit off. After all, why would the goals of a community be unclear? We're all here to make great software, after all. But are you sure that's what everyone in your community wants? More importantly, have you asked?

That's the important thing about an open source community that a lot of people might miss: every single individual has a reason for being there. And it's not always going to be about the software.

For some, it's about expressing their talent in a constructive way. For others, it's about relating to people who seem to understand them. Perhaps it's about building skills so someone can get a job.

You can see how the betterment and creation a certain piece of software may not be the end goal for someone's participation in your software community. It could actually be a means to another end. That means people are coming into your project with different agendas. This, in and of itself, is not a bad thing. Indeed, you want to have multiple points of view when working on projects, to help build better solutions.

But it should serve as a cautionary tale for anyone who wants to propose a new idea in a project and assume that everyone will want to go along with it. "Let's use golang" could be met with resistance from people who wanted to practice their skills on another development language. Or "we don't need a code of conduct" could alarm people who are looking for a safe community in which to participate.

The good news, this is not a terrible problem to solve. You can simply ask.

Community feedback surveys are not universally performed within open source projects, but they should be. Especially for projects with more than 20 people. Less than that, too, but smaller communities can have more informal conversations.

Creating Community Surveys

There are two main things to remember when working on a community survey: setting an objective and asking the right questions.

Setting an objective is relatively straightforward, if you make the objective focused. A survey should not be "I want to know everything about my community members." That sounds nice, but it's not really achievable. Instead, narrow it down to a more specific goal, such as:

• Exploring new development tools
• Adding new features
• Event goals and objectives
• User satisfaction

Asking the right questions is trickier. You want to get honest answers so you have to make the questions as neutral and unbiased as possible. So, "How much do you think Acme Tool sucks?" would be a bad question. Reframing it to something like "Please rate your overall satisfaction for Acme Tool." would be a lot better.

The best way to do this would be to let someone outside your community take a look at your survey when you think you have it done and have them look for instances of bias or leading questions. If they are outside of the community, then they won't be thrown off by any loaded questions you may have accidentally written.

However you go about getting the information from your community, remember to keep an open mind for the surprises that will come. Cast aside the assumptions you have been carrying, and move forward armed with the knowledge you have gained.

Image available under the CC0 Public Domain Dedication license.