Tag: Community

There’s a lot of buzz in the tech world around the word community. Perhaps stemming from the wrench that social media has thrown into the works, business folks have started tossing around terms like community content, community relations, and community management. But do they know what community means?

“You keep using that word. I do not think it means what you think it means.”

I’ve been a community leader in the open source world for the last eight years. Before that, I was a community member. You cannot be a community leader without being a community member. To understand what a community leader does, you have to understand what a community is.

1. A community is self-governing. Community members are empowered to decide the direction of the community. If you’re telling people what to do and how to do it, you don’t have a community. You have a workforce.
2. A community is social. I don’t mean it’s on Facebook or Twitter. Community members might use Facebook or Twitter, but they might use something old-school like mailing lists or IRC. What’s important is that people are talking to each other, getting to know each other, and making decisions together. Without social interaction, you just have a random group of contributors.
3. A community has a common interest. Community members will have differences on many topics, but there has to be something that brings and keeps them together.

Community leaders don’t set direction or dictate what gets done. That would work against the self-governing nature of communities. And they don’t keep projects or priorities secret. That would be anti-social. So what does a community leader do?

1. The first job of a community leader is to welcome new members. People will come and go from your community. That’s the nature of things. A lot of people will just stop by because they’re curious. If you don’t welcome them and give them a way to get involved, they’ll be gone before they’ve ever started.
2. A community leader keeps things running smoothly. If your community is trying to get things done (and when businesses talk about communities, they want those communities to do something), then someone needs to stay on top of those things. You can’t make community members do anything. But you can keep track of what they’ve decided to do and remind them. Leaders are like personal assistants to the entire community.
3. A community leader keeps the big picture in mind. You have to have your finger on that common interest that’s keeping your community together. When people get bogged down with the trees, you have to remind them of the forest.

Every successful community I know of works this way. And every time a company tries to set up a community, but ignores the nature of communities, it eventually fails. So, do you have a real community, or are you just treating your users like employees?

Recently, a user sent an email to the KDE documentation list complaining that the KDE4 documentation left him in the cold after upgrading from KDE3.  This is something the Gnome documentation team needs to be careful with as we think about the Gnome3 help.  We’ll have a lot of Gnome2 users who are disoriented, and it’s our job to help them.

Brad Hards replied to the user, pointing out that KDE documentation is a volunteer effort, and asking the user to contribute something.  I am entirely sympathetic to this response.  I understand the difficulties of trying to produce good help with a skeleton crew of volunteers.  But from the perspective of actually helping the user, it’s a complete fail.  And at the end of the day, we do what we do to help users.

Here is how I think one should respond to a message like this:

1. Sincerely apologize to the user.  Don’t make excuses.  Don’t use volunteerism as an excuse.  If your apology starts with “I’m sorry, but”, you’re doing it wrong.
2. Identify exactly what problems the user is having and how the documentation could have helped the user.  Try to keep an open line of communication with the user.  Do not try to get the user to do work.  Just try to understand his problem better.
3. Write some documentation to help the user.  Don’t worry too much about getting it plugged into whatever documentation system you have.  Don’t worry too much about making it a final copy.  The goal is to have real instructional information that can be reviewed.  Use a wiki or your blog or whatever you find most convenient.
4. Ask the user to review what you’ve written.  You’re not asking the user to be a copy editor or a proofreader.  You’re asking him to tell you if this new documentation is helpful.
5. Revise.  Repeat.
6. When the new documentation works, make sure to put it through whatever quality control systems you have in place and to get it integrated into your documentation system.

Here’s what this accomplishes:  First and foremost, it actually helps the user.  It takes a disgruntled and frustrated user and turns him into a satisfied user.  With this kind of personal attention, it might even turn him into a downright happy user.  Second, because we’ve helped the user by writing real documentation, instead of answering questions on a mailing list, we’re helping countless other users who will never take the time to email us.

Finally, by giving the user something very concrete to do, we’ve given him a low-barrier entry point for contributing to our community.  Maybe he’ll stick around.  Or maybe he’ll go back to whatever he was doing, just a little happier.  I don’t know.  But what I do know is that “Find something to do and do it” is not a good way to get new contributors.  “Here is a simple task that is relevant to you personally” is far more effective.

♫NP: Fred’s Slacks Pt. 1 by Mingo Fishtrap