#git: guidelines for helping

Helping quickly and effectively is much more of an art than asking for help. I could try setting up a rule book, but who knows how much of a difference it'll actually make. I can say something about what kinds of helping the #git operators have found to work well, though. I might throw in a few things about how to make helping easier, too...

These are not laws. They're thoughts you might want to take for a test drive or two. All we ask is that you be reasonable. If you can think of ways to be reasonable that deviate from the stuff below, feel free to try those instead... and do let us know about your ideas so we can improve this page.

• Bit bucket: if you start getting annoyed with helping someone, by far the best thing you can do is to completely stop talking to them. Yes, that means not even saying something like "I'm going to stop talking to you, you idiot" – just say nothing at all. Good ol' /ignore can help with this, but with just a bit of practice it's fairly easy to do without, too, and you're more flexible that way (and as an op you want to know when to wield the banhammer, anyway). Extensive pseudo-empirical pseudo-research has shown that there is no better way to deal with annoying people on IRC. To maximize your personal happiness, feel free to think spiteful things to yourself about the person, or turn your mind towards something completely different – something that fires up the good feelings.
  No, I don't mean hard drugs.
• Politeness matching: please be polite – at the very least, as long as the person you're helping is being reasonably polite and reasonably non-obstinate.
  If you believe someone is misbehaving, strategically speaking the best thing to do is call them out on it in very specific terms with fairly neutral language, e.g. "you're doing X right now and I think it's distracting from your problem. How about Y?" Of course, if that meets scorn or more unreasonable behaviour, all bets are off.
  If, however, people are demonstrating attempts to learn/understand, we think it's a bit unfair to stop being polite even if they may seem quite dense sometimes. If you get too frustrated, consider pulling a bit bucket on them instead of lashing out.
• Detail bandwidth: we don't want to recite manpages or tutorials to users, of course (not least because that way they never actually learn anything), but we also don't want to send people to $search_engine every time they ask a question... that would be silly. After all, the reasonably experienced ones among us know that there are plenty of worthless, ill-conceived, misleading articles about git on the web, and it can be hard for new users to tell good from bad.
  So, if you want to save yourself some typing, please refer users to concrete sources that you're reasonably sure are relevant to the user's question and reasonably likely to clear up the particular kind of confusion the user seems to have gotten caught in. We try to maintain links to sensible sources in the bot's triggers, but it'd be cool if you read them before using them as your go-to explanation for users. Of course that's quite a bit of work, so many people just join the happy bandwagon and recommend the same resources everyone recommends.
  Find the list of triggers overwhelming? Try searching for relevant keywords in that page. That's the only way you can actually use the list these days.
• Data mining: it's tempting to jump to conclusions about what the problem is after the user has said very little. As you get more experience with helping, you'll get a better sense for when to ask for more details and when to go with a stock response. If in doubt, ask more – especially if there's a chance that data may get lost due to a misunderstanding.
• Obvious stuff: if a problem takes unusually long to figure out (given similar problems you've helped people with in the past), take the time to make sure that the user didn't make any obvious (to you) mistakes. (Of course, don't rub it in... that's being a jerk. See politeness matching.)
• Many words: if someone isn't getting what you're trying to say, say it again, but present the idea differently. Sometimes it helps to start out with a simplified (and maybe slightly incorrect) version and then build on the understanding the user gains from that. In any case, the more different ways you manage to describe the same thing, the higher the chance that it will click for the user. I like people leaving feeling smarter than they did before... both for humanistic reasons and to feed my massive ego. Feel free to copy me.
• Fortify your approach: sometimes users will think you're making things way too complicated (be it due to your quite verbose explanation, your insistence on using a particular terminology, or the many clarifying questions you're asking), and some of them may be quite vocal about their dissatisfaction with that. Maybe they're right, and you're trying to be completely correct about details that are almost certainly irrelevant in the given situation. Or maybe they're wrong. In that case, what do you do?
  It's important to realize that this is not an attack against you – the user probably doesn't understand some of the finer (yet critically important) points even though they think they know all the important things. It happens to everyone, right? So, they're trying to save time that you know better should not be saved.
  In my experience, what doesn't work terribly well is curtly explaining that... but let's say you recall a situation in which someone else got the same information explained to them (or the same questions asked, etc.), and as a result a lot of extra work was avoided. It may be worth a shot telling that story (doesn't even have to be a hundred pages).
  Or maybe you don't, but you can imagine two situations that could happen if you gave in and skipped some stuff – one with an acceptable result, one without. Briefly outline the two and give them a choice ("okay, suppose we skip all that... two things might happen: either X, or if we're out of luck, Y. do you want to take your chances?") – now it's up to them. If they still prefer to skip the details, they'll have no one to blame but themselves if things blow up in their face. Not an ideal outcome, but the one they explicitly chose. You can't force people to be happy. ;)
• Easy-going: despite all of the stuff above, we're not putting professional standards on you. Jokes, for instance, are perfectly fine and even encouraged – we don't need the channel to become too boring.