In the self hosting world, we all run into various issues trying to set up our services and apps. But it's how we handle ourselves when we report those issues and request support that differentiates us from one another.
Some find it easier to admit fault and move on, but some have much thinner skin. They are unable to admit fault and instead go down an unproductive path that leads to more frustration for both the dev/maintainer and the user.
Below I will list 7 stages that some users go through. The first stage is inevitable, we all start there. Some users go through some of the other stages, some may skip a stage or two and some go all the way. Each stage leads to more negative behavior and frustration.
Before I get into the stages, I'd like to clarify that the below write up is my own and while I'm a member of the Linuxserver.io (lsio) team, I do not wish to speak for the team or the other members. I use the royal we as I started compiling this originally with the intent of publishing on the lsio blog, but then thought better of it. All of these opinions are my own, hence the personal gist.
Also, I'd like to remind you that the entire Linuxserver.io team (like most FOSS devs and maintainers) are volunteers who do this in their spare time. All team members have full time day jobs (or two) and most have families and other responsibilities. I do this for fun. Nothing I do for lsio benefits me at my day job or helps with my career. While I enjoy developing and maintaining docker images, I also enjoy helping out others. Several people I know in real life have described me as one of the nicest people they met. I am not aware of anyone calling me rude behind my back. On the other hand, being rude is something I am often accused of under my alternate (lsio) identity. One might wonder where this discrepancy stems from.
This write up is something I compiled over time based on my interactions with users. Not all users go through the stages after the first, and many users are very nice and courteous. But it's often the ones who are not that end up leaving a longer lasting impression.
To be perfectly honest, there have been many times where I got so frustrated with an interaction with a user that I put myself into support timeout. For a week or two, I ban myself from even looking at issue reports or support requests to preserve my mental health. There were a couple of times I came close to saying Screw this, I'm done. I get enough stress and burnout at my day job. I don't need extra stress from my hobby. At the end of the day, I do this because I want to, and because I like to. I do not owe anything to the users. Most know this, some forget it, and a few need to learn it.
The user has tried something and it didn't work. It happens. Often the user has missed some detail in the documentation, and is unable to spot the mistake. Sometimes there is actually a bug introduced either by us or the upstream project. And sometimes our docs may have inaccuracies, or may be out of date.
The user gets frustrated and opens a Github issue, or a thread on our Discord, or posts on our forum.
After a period, there may be no replies to the issue or request for a variety of reasons including:
- The user asked a question that was asked many times before (did not search through existing issues)
- The user did not include sufficient information to reproduce the issue
- We simply did not have time to get to it (we triage issues and dev work because there is too much work and too little time)
The user gets agitated and demands an answer.
Sometimes we post a short response, which could be a couple of words or a link to another issue, or a link to an answer that was provided previously.
Let's face it, we are not running a five star hotel. We are not going to roll out the red carpet to any user who has an issue. We will not be using pleasantries in our replies. We don't have the time or the resources to do that.
We have a handful of active daily team members supporting more than tens of thousands of users. Our discord server alone has more than 35,000 users.
We are volunteers and we do this in our spare time as a hobby. Support is not my favorite thing to do personally, but I find it helps with dev work as I can identify issues and bugs through meaningful conversations with users. Unfortunately a great majority of these support interactions are simply pointing the user to the necessary information and rarely meaningful from a development perspective.
Unfortunately in some cases the user immediately doubles down on their initial claim, often without even reading through the link that was provided. It often includes verbiage like Did you even read my issue? It is not working..
We reply with a sentence or two pointing out that the link provided contains the information they need.
Here comes the initial personal attack. Often a claim of the dev/maintainer being rude. As described in Stage 3 above, we don't do pleasantries. We don't apologize that the user is having issues. We don't roll out the red carpet. Amazon Chat Support may do it, but we're not it.
I'll admit I'm often curt or direct. That's because I don't have time for anything else but the answer to their question. I use the minimum amount of words (sometimes a link) to point them in the right direction. Some people mistake that for being rude. Oh well, that's on them, I guess.
When it's pointed out that the user indeed made a mistake or did not follow the instructions exactly, the user immediately gets defensive and looks for somebody/something else to blame.
Most common target is our documentation. If only I had a dime for every time I heard your docs are wrong.
We constantly revise our docs to make them easier to follow. Most of our readmes are a short single page with bullet points. We provide sample compose yamls that need a simple copy/paste and some minor modifications.
Even for apps that need external databases (some dbs we don't even have images for), we try to include compose yamls and init scripts so they can get them up and running.
In this stage, we state that the docs are accurate and sometimes provide our own test results following the instructions from the docs.
At this stage, the user's ego is significantly bruised. Attempts to double down or shifting the blame did not quite work. The user lashes out with more personal attacks.
Common responses include:
I went through the other issues and it's clear you have an attitude problemI saw that you're rude to all the other people and not helpful at allI used to use Linuxserver.io for my containers but I'll switch to other containers from now on
This stage concludes with us warning the user that personal attacks are not welcome. While this can lead to a ban, we have only ever banned a couple of users from our Github, and they were due to repeated and excessive insults and profanity.
At this stage, the user may try to spin the original issue into something else entirely to alleviate any fault of their own and continue to cast the dev/maintainer as the villain. It can be something like Well, I wasn't even asking for help. I was only trying to help you fix your stuff so I can help the community. Right. Even though they opened an issue about not being able to get it to work, and then blamed the docs, and when it was pointed out they did something wrong, they spin that into I'm trying to help you but you're being so rude.
Thanks, but no thanks.
It's real easy. If you missed something, and someone else points it out, just go with an Oh, I'm sorry, I must have missed that, or My bad, or even a simple oops.
That's literally all it takes. Easiest way to de-escalate a situation. No need to double down or shift the blame as they only lead to escalation, which leads to a lot more frustration and time wasted by multiple parties.
The first stage happens to all of us and it's inevitable. But how we handle ourselves after that stage is entirely up to us.
I'll admit I get the urges to go down that path if my ego's feeling somewhat fragile that day. But I always remind myself there is nothing to be gained through that path.
Here's me de-escalating with a simple sorry for the noise: syncthing/syncthing#8318 (comment) I failed to pay attention to the docs and used the wrong version of go to build it. When I realized my mistake, I apologized and provided more context so anyone else making the same mistake can find it on Google (hopefully). I didn't try to shift blame. I didn't claim their docs were unclear or wrong. I also didn't blame the dev for being rude. He didn't include any pleasantries, and I expected none of it. He simply said I do this and it works and that was sufficient for me to realize my mistake. I wasted only a little bit of his time, no more than the minimum necessary.
Here's another one of me swallowing my pride: hedgedoc/hedgedoc#639 (comment) Yup, I did something silly, and I acknowledged and apologized immediately.
Did it hurt me to do that? Not one bit. And I saved so much time and sanity by not going down that path.
Be kind to each other and be thankful for others being open and willing to help. Help them help you.
- aptalca