#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
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
- 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
- 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.