websites/dennogumi.org-archive
Archived
1
0
Fork 0
Code Releases Activity

New post: I have a problem...

Browse source
This commit is contained in:
Luca Beltrame 2016-05-29 10:05:52 +02:00
commit c483fe83e8
1 changed files with 54 additions and 0 deletions
Download patch file Download diff file Expand all files Collapse all files

54
_posts/2016-05-29-i-have-a-problem.markdown Normal file
View file

@ -0,0 +1,54 @@
---
categories:
- KDE
- openSUSE
comments: true
date: 2016-05-29 09:48:50+0200
layout: page
tags:
- KDE
- openSUSE
- forums
title: I have a problem...
---
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. ;)