5 ways to answer questions the open source way

No readers like this yet.
open here

Opensource.com

Eric Raymond's How to Ask Questions the Smart Way was published in 2001 and has been very popular ever since. It gets referenced on my local Linux User Group mailing list with some frequency (usually alongside an admonishment to stop top-posting). To be sure, it contains a lot of good advice for how to perform research, how to frame a question, and what salient information is generally a minimum required to solicit help.

And yet, I think it could have been done better. Raymond spends roughly 10,000 words telling people what is expected of them when they seek help, including how not to react like a loser, but why not some words on how to answer questions in a helpful way?

In an effort to remedy this glaring oversight, I share here some guidance I've learned over the past dozen years participating in open source communities, as both a novice and an expert.

Be compassionate

Much of Raymond's treatise is predicated upon the assumption that the people providing answers are all very busy people, and their time is not to be squandered.

"We take time out of busy lives to answer questions, and at times we're overwhelmed with them. I counter that the people asking for help are equally very busy people, and deserve to be given the same respect that you expect."

Many times, people asking for help are frustrated. They may be under a deadline. They may have inherited a problem about which they know next to nothing. Solving the problem is not what they want to do–they want to do whatever it is that the problem is preventing them from doing.

The person asking for help is already taking time out of their busy day just to ask for help. Quite often in this day and age, the most expedient solution to an open source problem is to stop using open source. Anyone who takes the time to ask a question deserves our support.

Be supportive

Raymond's second piece of advice about providing answers is "reply to a first offender offline." The very verbiage of this advice makes clear that he perceives a power differential, and that people who don't ask questions in the "one true way" are offenders.

Are we, as a group, more interested in enforcing a specific set of behaviors, or are we more interested in fostering a culture of respect, collaboration, and participation? To view interlocutors as "offenders" ensures the former. I'm much more interested in the latter.

So if someone doesn't follow every one of Raymond's pronouncements for asking a good question (or, God forbid, top-posts!), I say, "Who cares?" Be nice to them. Demonstrate that they are amongst friends. Gently and positively encourage them toward preferred behavior, but do so in a way that makes sense. There's a history to many of the cultural elements of open source, and new members won't be privy to that history. To scold, reprimand, or "correct" people, offline or online, is to promote a culture of negativity, and to preserve the perceived power differential.

Why not share–openly–the history of why cultural norms are what they are? To do any less is to say that things are the way they are by simple fiat.

An important corollary exists: be willing to accept that times have changed and the original reasons for any specific culture behavior no longer obtain.

Be responsible

If you subscribe to a mailing list with the intent of both asking and answering questions, take some responsibility for the fact that you have made a conscious choice. Other list participants aren't coming to you personally, begging for your wisdom. They're casting their questions into the ether, eagerly awaiting an answer from anyone. If you're too busy to deal with that, then perhaps you're a member of the wrong mailing list.

Be patient

If you're a member of a technical mailing list, you must accept that there will be a steady stream of new participants joining the list. New members will be ignorant of the list's cultural norms. They may never have heard of Eric Raymond before, and do not realize the implied significance of your link to his screed.

You should be as patient with the first new member as with the 10,000th new member. These are people who have taken their time to participate in the forum, just as you have. In time, they too will be expected to shepherd new members, such that the burden of cultivating culture is shared and distributed.

Be involved

Successful communication requires real effort from all parties involved. It is not acceptable to put the entire burden for successful communication onto the person who is struggling to find an answer to a problem. If you want to help, you need to accept that there is a burden to you for doing so. You'll hear the same questions again and again. You'll have to repeat your answers again and again. You'll misunderstand people. People will misunderstand you.

The end result of your efforts will be a gradual increase in the number of like-minded people willing and able to help share the burden of providing help to those who need it. And isn't that community empowerment one of the reasons we all like open source to begin with?

Adapted from How To Answer Questions The Smart Way. Reposted under Creative Commons.

User profile image.
I am an advocate for Free Software. Find out more about me.

3 Comments

Great article. Thanks for sharing. :)

Raymond provides advice on answering helpfully, and you even linked to it. To what "oversight" are you providing a remedy? Maybe the introduction could be improved by acknowledging that this article expands upon advice, rather than filling a vacuum.

In reply to by Don Watkins

The world is drowning in injustice. This extends to the realm of IT, where, for example, Microsoft and the BBC are working hard to undermine the Raspberry Pi system by developing an alternative. The BBC will be using public finds for this. Why not do your job and report on that - it's far more relevant than "how to answer questions" in an article that's a rehash of someone else's work.
Why aren't you more angry over the injustice?

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.