Add the whole blog

content/post/2016-05-29-i-have-a-problem.markdown

@@ -0,0 +1,54 @@
+---
+categories:
+- KDE
+- openSUSE
+comments: true
+date: "2016-05-29T09:48:50Z"
+tags:
+- KDE
+- openSUSE
+- forums
+title: I have a problem...
+disable_share: true
+---
+
+Every day, a sizable number of people posts problems on the [KDE Community Forums](https://forums.kde.org) and the ever-helpful staff does their best to solve whatever issues they're facing. But what *exactly* does one do when this happens? This post provides more insights on the process.
+
+**NOTE**: The following applies to my workflow for the [Kontact & PIM](https://forum.kde.org/viewforum.php?f=215) subforum.
+
+## Step 1: Someone posts a problem
+
+The questions posted are various, and range from simple tasks ("how I do XXX") to very specific workflows. It covers a large spectrum.
+The first thing I do when reading a post, is to go through a "mental checklist":
+
+1. Is this known already?
+2. Are there enough information?
+3. What distro is this user on?
+
+Answering point 1 means I have to keep up with development of KDE software, or if I don't know, check the mailing lists and blog posts to see if other people have raised the issue (checking Bugzilla is a last resort, due to the very large number of bugs posted there). It also helps running the latest KDE software.
+
+If point 2 isn't satisfied, I ask a few more questions following the [General Troubleshooting](https://forum.kde.org/viewtopic.php?f=14&t=38828) guidelines. These include conditions for reproduction of the issue, if it still occurs with a new user account, and so on.
+
+Point 3 is related to point 2: not all distros are equal, so knowing on which distro the user in may reveal distribution-specific issues that need to be addressed directly downstream.
+
+## Step 2: Going deeper
+
+If the issue isn't solved even like this, "we need to go deeper". Usually, time permitting, I try to reproduce the issue myself if it is within my reach (for example, if it doesn't involve company secrets on an internal server ;).
+
+If I can reproduce it, I tell the user to file a bug, or workarounds, if I found any. If I can't, I ask a few more details. Usually this can lead to the issue being solved, or to a bug report being filed.
+
+## Step 3: Communicating
+
+Sometimes the issue is unclear, or it is behavior where the line between feature and bug is very blurred. In this case, I need to get information straight from the horse's mouth. I hop on IRC, and I address the developers directly, usually pointing at the forum thread, and asking for details.
+
+Sometimes they follow up directly, sometimes they report me useful information, and sometimes they tell me its' a feature or a bug. In either case, I report the information to the thread starter. In rare cases, the issue is simple enough that it gets fixed shortly afterwards.
+
+## Stem 4: Following up
+
+Unfortunately not all bugs can be addressed straight away, so sometimes issues stay lingering for a long period of time. However, sometimes a commit or two may fix it, with or without a bug being filed. If I notice this (I do read kde-commits from time to time ;) I follow up on the thread writing about it being fixed, workarounded, or whatever.
+
+## What's the point of this post, anyway?
+
+Good question. ;) I mean this to show how much work can go into a "simple" user support request post on the KDE Community Forums. This is even more important to point out since apparently, frustration can make people tell that others' work is worthless.
+
+So, if you ever bump in any of the forum staff, be sure to offer them a beverage of their choice. ;)