3. Be lenient when possible
A few years ago, behavioral economists examined the decisions of eight Israeli parole board judges. Since the judges were all Jewish and the prisoner requests they evaluated were a mix of Arab and Jewish offenders, you might suspect that any bias present would be ethnic or religious. Actually, decisions were most biased by the time of day the judge considered the case:
Those little circles represent food breaks (breakfast, snack and lunch). If a prisoner was lucky enough to have their case heard shortly after one of those meals, they could expect a favorable ruling about 65% of the time. On the other hand, if they got stuck toward the end of a session when the judge was likely to be tired and hungry, there was little chance the judge would rule against the status quo. The authors of the paper suggest a physiological explanation: ego depletion.
We get tickets that share a lot of commonalities with parole hearings. In particular, people can get banned from asking questions on some of our sites. We've been working on ways to help people avoid these bans, but with 20,000+ new users signing up each week, there's bound to be a few people who just don't learn how to ask good questions. At least some percentage of those users appeal to us directly.
I actually am glad they do. For one thing, sometimes our automated system makes mistakes. Without going into the details too much, it's possible for a user to make a blunder in their first question or two such that they get banned even after working hard to improve their later questions. While we can't remove the ban directly, we can disassociate posts from users to let them post again.
The other reason I like seeing appeals is that it's reassuring that our system is so often fair. Roughly 2/3 of the people who write in have absolutely no business asking questions on a site for developers. You gotta feel for these folks who have been stuck with code they don't understand or given programming tasks without access to proper training. Asking on Stack Overflow probably doesn't even help many such users since they don't seem to understand the answers. Often they ask essentially the same question over and over again---only with slight and inconsequential variations. Blocking them from asking more futile questions, as harsh as it sounds, is the right thing to do.
Many of the remaining third who get a reprieve end up banned with their very next question, which is discouraging. But for the rare person who does go on to be a productive user, it's important that we gave that final opportunity. And that's why your mother always told you to eat your breakfast.
4. Apologize to a weird degree
Apologizing never hurts as much as we think it will. My favorite
[email protected] replies is:
I'm sorry you had a bad experience on the site.
When it comes to coding Q&A, Stack Overflow doesn't have much competition and it's tempting to behave like Ma Bell:
For every person the site drives away, it seems like there are two more clueless users to take their place. We don't need to care. But I really am sorry people have a bad experience on one of our sites and so I apologize. Profusely.
And you know what? It's never cost me anything. Sometimes people are grateful and go away happy. Sometimes people write back with angry words. Either way, an apology can only help. If I remain relentlessly polite, I know that we can ignore angry responses from angry people. If we get a polite response, I can take credit for handling the situation well. Being rude back can only make matters worse.
5. Use the canned responses
In the heat of the moment, it's easy to get snippy with someone. Someone will write in to tell us how awful Stack Overflow is because they were downvoted, their question was closed, a comment was deleted, and/or their post was edited. Rarely do we find that someone was actually mistreated. More often, we find that the person writing to us has managed to anger a bunch of others users on the site with their own terrible attitude. I'm tempted to write a "strongly worded" response in these cases.
Instead, I use one of over a hundred standard emails that was written and refined over years. Yelling at this sort of person won't make them better users; they are the definition of lost causes. There's no chance they are going to become model users, so why waste the time composing a message?
Our goal with macros is to end the interaction in as few emails as possible. The best way to do that is to help people get back to whatever they were doing when they decided to contact us. The worst way to do this is to start an argument. Having a full stable of macros saves time since we can trot out pre-written solutions to common problems. Using them also makes it easy to ignore hostile language in the ticket and focus on solving the user's underlying problem.
Next time: reducing 3rd party tickets.
Send feedback by creating a GitHub issue.