summaryrefslogtreecommitdiff
path: root/manual/en
diff options
context:
space:
mode:
authorLars Wirzenius <liw@liw.fi>2016-02-20 14:45:18 +0200
committerLars Wirzenius <liw@liw.fi>2016-02-20 14:45:18 +0200
commitef690b8dbc0d9747db64cdb300779c959aaa22de (patch)
treebbfb596df8e243d3763a823bbcd4977fe3164977 /manual/en
parent0753490b37583f55f0eb7af0faa5ba329d6fd1d4 (diff)
downloadobnam-ef690b8dbc0d9747db64cdb300779c959aaa22de.tar.gz
Write section on helping support users
Diffstat (limited to 'manual/en')
-rw-r--r--manual/en/700-contrib.mdwn62
1 files changed, 62 insertions, 0 deletions
diff --git a/manual/en/700-contrib.mdwn b/manual/en/700-contrib.mdwn
index dde0db8a..ec454aa9 100644
--- a/manual/en/700-contrib.mdwn
+++ b/manual/en/700-contrib.mdwn
@@ -42,6 +42,68 @@ chapter for suggestions on how to contribute to the list.
Helping support users
---------------------
+Perhaps the easiest way to participate in the project is to help
+support other users of the software. This is easy, and doesn't
+necessarily require more than being able to use the software oneself.
+Yet it is quite valuable, as it frees others from doing that. Even
+with the highest quality, easiest to use software, there's always some
+need for user support:
+
+* Code can be wrong, and a user may experience this. Analysing the
+ situation and isolating the bug is an important part of the software
+ development process.
+
+* Documentation can be wrong, or out of date, or written in
+ anticipation of a feature that doesn't exist yet.
+
+* Some people have misunderstandings, due to whatever reason, which
+ leads them to have problems when using the software. Figuring out
+ what the actual problem and its cause are can be a time consuming
+ process, but often does not require any special skills, except for
+ patience and a willingness to ask a lot of questions.
+
+In the Obnam project, the best way to help out with this is to
+subscribe to the `obnam-support@obnam.org` mailing list or join the
+`#obnam` (irc.oftc.net) IRC channel, and start answering questions.
+
+It's OK to not be an expert. Helping others is a great way to learn.
+If you make it clear you're not an expert, but are trying to help
+anyway, usually makes others appreciate your help even more.
+
+Some suggestions on doing support work:
+
+* Try to understand what the person needing help is actually trying to
+ achieve, rather than answering their literal question. Better yet,
+ do both.
+
+* You don't need to have the solution to respond. A quick, but
+ incomplete answer that nevertheless moves the discussion forward is
+ helpful. Even if you don't know the correct answer, it's good to ask
+ a question that results in the person needing help providing more
+ information, or finding the solution themselves, or inspires someone
+ else to discover the solution,
+
+* Always be helpful and polite. Never respond with things such as
+ "read the fine manual" (or RTFM for short). It's OK to say that the
+ answer is in the manual, but then provide a link, and possibly also
+ a quote.
+
+* People who need help are often frustrated, and sometimes desperate,
+ because they've tried and tried to solve the problem on their own,
+ but have failed. This can leak through their messages. Ignore it,
+ unless they actually become impolite, at which point its probably
+ best to escalate the situation. Avoid getting into a quarrel about
+ who's right or who said what and what did they mean by it.
+
+* It's better to not respond at all, than respond while irritated,
+ annoyed, or angry. It's more important for the project to maintain a
+ polite and helpful atmosphere in the long run than to solve any
+ current technical problem.
+
+In short, if you do your best to be polite, friendly, and helpful, go
+ahead and respond.
+
+
Writing and updating documentation
----------------------------------