Produktive Issue Tracking in Open Source
I have been doing IT “things” for roughly the past 27 years. Within that timeframe, I came across the Open Source “Movement” around 1998.
What caught my attention with opensource immediately, was the fact, that I could interact with those projects. I made not needed money (which I did not have as a schoolkid and a student) and I did not need much education in the field.
I very early started communicating with those Developers and Admins in the field, first in person with administrators at local companies, and the local university, later on with emails and irc. It was not always easy to have that communication. I am not a native english speaker. As a result the process of communicating with developers around the world enhanced my english skills.
Still, via email you had to wait, on irc you had to check the timezones in which the developers or administrators you wanted to reach where availably. So I spent mainly nights at these channels of communication, as most of the developers and admins had either their day jobs, or they were somewhere on the other side of the planet.
Over roughly the past 8 – 10 years a new technology arrived on the “scene”, the so-called issue trackers. From extraordinarily expensive ones, where you pay per customer, to totally free ones, to ones actually free and you don't even need to host them.
A very popular remotely hosted and free tracker nowadays is github . it enables developers and administrators to share their software/scripts with the community open and freely.
The github issue tracker enables users of their “product” to get in contact with those developers and administrators. I can leave a message, maybe add a label to it (if the “producer” of that software allows me to set labels) without much of a knowledge. I may even leave pictures and attach files to the message. Which make it easier for the developers to understand possible bugs or wishes for enhancements.
Issue trackers are a central tool in most projects by this point in time. And while they are very helpful by design, without a few basic rules, they could also destroy a project in an unrepairable way.
Imagine, I write an issue about your software. While my formulations are usually rather clear and non-aggressive, you might fall victim to the fact. That the message I am leaving reaches you at a time where you feel vulnerable, or maybe you're sick and in bed, etc. That is something I couldn't have known.
As a result, you're slightly aggressive, getting harsh on me and starting to insult me. Now theres the problem. Because you wherenot objective, and did not took the time first to think about what you wrote. Now you have your reply to my message showing to everyone on the tracker.
While this might be not a big one. If this continues to happen more than once, i.e. you're a team behind a project. Future users of your software might decide not to post about bugs in your software on your issue tracker. Instead, they might decide not to use your software at all.
IF you wish your project to grow, you cannot ignore the user issue tracker messages either. As they will see theres no progress, and they will start ignoring your project in favor of “active developments”.
Do not get me wrong, you do not need to fix everything five minutes after a message about it arrives, but showing users that you care about their input is crucial, if you wish to have users using your software. I.e. just is leaving a short answer like “I don't yet understand what you told me, please could you explain a bit further” or “I am working on that, I will keep you posted if I find a way to fix these makes a whole lot of difference.
If you have the urge to insult the user, take a step back, maybe take a walk outside, a deep breathe and think what makes you feel so insecure, that you feel that you need to push someone else, who you don't even know, down.