Log in

No account? Create an account
Giving a Remarkable Help Online - Shlomif's Technical Posts Community [entries|archive|friends|userinfo]
Shlomif's Technical Posts Community

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

[Links:| Shlomi Fish's Homepage Main Journal Homesite Blog Planet Linux-IL Amir Aharoni in Unicode open dot dot dot ]

Giving a Remarkable Help Online [Oct. 13th, 2009|06:37 pm]
Shlomif's Technical Posts Community


[Tags|, , , , , , , , ]
[Current Location |Home]
[Current Music |Sofiya Fedyna - Track You]

Remarkable Customer Support as it applies to voluntary projects

One of my favourite Joel on Software articles is "Seven steps to remarkable customer service". While the article is oriented towards software shops it has universal implications. Quoting from the article:

Here are seven things we learned about providing remarkable customer service. I’m using the word remarkable literally—the goal is to provide customer service so good that people remark.

Today I'd like to write about providing remarkable online help on the various online forums of Perl. Online help is similar to customer support, only we don't charge for it, and it is done by volunteers. Nevertheless, we do have an interest to provide good online help, because otherwise we will get fewer people who use our project. They are still our users/customers even if they don't pay us.

So let's start.

How not to lose a single soul.

One day (which happened to be my birthday) I chatted on Freenode #perl when someone with the nickname of sas123 joined and said he couldn't understand references. We naturally referred him to perlreftut, but even after reading it, he said he did not understand. Some of the channel regulars said that perlreftut was written well enough that he must have been able to understand. However, I recalled a a Hackers-IL thread called "Smoking out pointer-impaired minds?" where we discussed why understanding pointers or references is hard, and why many people will have trouble understanding pointers at first.

As a result, I invited him to #perlcafe, and we held a long discussion about what Perl references were. And he eventually was able to understand them. Such extraordinary willingness to help is something that people will remark upon and recommend to their friends. I do not think this discussion should have stayed on #perl because it would have reduced the Signal-to-Noise ratio and prevent other people from getting help (and it did take a long time). However, I think the #perl participants should have told sas123 that they will help him on a different channel right away instead of telling him that he's beyond hope.

Communities around FOSS projects should try to avoid losing even one newcomer. That's because people who've been disappointed by bad social treatment will rant about it to their friends, vent about it in their blogs, or worse. And naturally, several individual people add up to a lot pretty quickly.

I still recall an incident, where someone joined #vim, said he's been using GNU Emacs or XEmacs for many years, and that because the people on #emacs have insulted him and treated him badly shortly before, he decided to switch wholesale to the alternative - Vim. When I suggested that he could use a Vim add-on, that could make it behave more like Emacs, in order to ease the transition, he did not want to use it saying that he'd rather do the conversion properly.

So the Emacs people lost a long-time user, who opted to painfully re-train himself to use something completely different, losing years of habit and customisations. As members of the Perl community (for example) it is much more likely that we will lose a new member who can easily choose Python, PHP, Ruby, Lua or whatever. So we need to provide a remarkable online help to keep them.

It's not new.

Other people inside and outside Perl have been echoing similar concerns. See for example what Andy Lester wrote about "Don't optimize for yourself in communities" on Perlbuzz, and the Kirrily Robert's "Geek Etiquette" blog.

A tougher nut to crack.

A few months ago #perl on Freenode was frequented by a certain newbie who needed to use Perl for her site about role-playing games. She needed too much hand-holding and often made many steps backwards and as a result one of the ops has eventually banned her. One day, when I was on Freenode, she private messaged me and explained the problem, and I invited her to #perlcafe or #perl-cats to ask her questions and get help with her code there.

Now we help her at #perlcafe . She still requires a lot of hand-holding, often won't immediately understand why the advice we give her is good, and is often too much utilitarian and not focused enough in her quest for Perl knowledge. But she still seems to make some progress, and we now consider #perlcafe as an "incubator" for her (with all the Science Fiction implications) that will make her ready for public consumption on #perl.

Should her training stay on #perl? Naturally not. But, on the other hand, she still should not have been banned, and instead a few people should have volunteered to help her on a different channel.

How to do it.

The old adage of "Be conservative in what you do, be liberal in what you accept from others" applies to human communications as well. On help forums, we can expect many people who are tactless, non-native speakers of English, who may incorporate many paradigms from their native tongues or from popular Anglophone culture, with relatively bad English, in a bad mood, not very knowledgeable or clueful, with personality defects, and/or who have not read the FAQ or the needed documentation. On the other hand, we should always be friendly, polite, with the best English that we can emit, and being as helpful, accessible and non-laconic as we humanly can.

As annoying "clueless" newbies can be, they still can and often do improve and they are still human. And being hostile to them can have a snowball effect. By being courteous and helpful to newcomers, we can also further educate them on how to behave in our own or other on-line communities which will in turn make the long-term experience better.

As a pragmatist, I dislike what I call the "grand disciplinary" approaches, which say that people should have a lot of discipline to maintain a certain state. These things almost never work. I much prefer the more practical approaches of doing small and one time things like changing the channel's topic or trying to do it a few times, which ends up turning it into a habit.

Building a friendly and helpful environment is not that hard, and we can make a better one by several incremental steps. And it is worth it.

Some final notes.

A final note: I may have focused on Perl and Freenode's #perl here, I only did it because Perl is my area of expertise and because I'm an active member of Freenode's #perl ("The poor of your city come first", etc.). However, I think that #perl on Freenode is generally a great resource for beginners and experts, and I've seen much nastier IRC channels and Internet forums in general, including on Freenode. So don't take me the wrong way - all I'm saying is that there's still room for improvement.

Thanks to Andy Lester, Trashlord and Rick for giving some input and corrections about early versions of this article.