Make it easier for users to send feedback!

My claim is that software developers could get ten times more feedback from their users if it were easy to do so.

And feedback is valuable!

Let’s take an example:

I use Gnumeric in which I recently found an issue.

I decide to report it.

My optimism rises a couple of notches when I see (under Help) the menu item: ‘Report a Problem’

In the webpage that opens I click ‘New Issue’ and I am asked to log in.

However, I do not have an account to log in to, and moreover, on this particular page (gilab.gnome…)
there is a message:

Please note that due to spam, new user registrations are disabled.
Please use 3rd party logins for logging in if you don’t have an
existing account

Wtf is a 3rd party login? (yes, there are users out there who do not know what this is…)

Result: I abandon.

What is wrong about this feedback process?

— Just about everything.

First of all: psychology

One of the first laws of customer satisfaction (in any business) is that one discontent customer out of eleven actually complains!
Which means that customer complaints should be taken seriously! One complaint means eleven disgruntled customers.

In the software business the customer is something more: he is valuable because he is the ultimate quality controller.
And he does it for free – if the developers makes it easy for him…

I have been working on both sides of the fence: both as a developer and (obviously) as a user.

To be perfectly honest, developers don’t like feedback, because feedback means trouble, and it means a dent in my ego as a developer since it will probably reveal that the software I have developed is not perfect after all.

On our side of the fence, we would like the feedback neatly pigeonholed and databased, and why should we not ask the user to do this job for us?

So we simply DEMAND it: the user (with no prior knowledge of how bugs are classified) is asked to pigeonhole his bug.

He MUST do so: otherwise we will NOT accept his feedback.

On the user side of the fence sits someone who is annoyed because his work is impeded. He has a job to do, and it has suddenly become more difficult or impossible.

He has little patience, but – if the preocess is easy – he is willing to send feedback.

If he must log in to some account where he will be confronted with a list of previous bug reports and is asked to classify his bug, he will probably quit.

How do I know?

Because I’ve done so numerous times, and there are at least a couple of hundred bugs I have not reported because of this process designed by imbecils!

How should it be done?

It is simple:

There should be a box labeled description where the user can describe – in his own words – the bug or problem.

And there should be a button: ‘SEND’

In this I may sound naïve, but I have personally (as a developer of in-house company software) used this principle.

We received LOTS of feedback which was sorted on keywords, and based on the sheer number feedback alone, the most important issues to fix were easily identified.

Labels such as ‘CRITICAL’ etc. became redundant. We let the numbers speak – as if they were votes.

Conclusion for now

This is an outline of an article which attacks ‘the way we do things around here’ and will probably fall on deaf ears.

But perhaps we should listen

If you should find it interesting, I am willing to write an article about it.


Nicolay Bøhn


Welcome, @nifrebo! While I agree with you generally, I’m not sure Fedora Magazine is the best venue for this. You may consider pitching it to, with the insults removed.

1 Like

Sending reports is a complex issue, primarily because Fedora is downstream for all our software, i.e., Fedora doesn’t develop it, we distribute it (as a Linux distribution). So, the only general location that a Fedora user can send reports is at the Fedora Bugzilla (not for Flatpaks from Flathub though!). Package maintainers will then triage the issue and send it upstream. But, users can also send reports upstream directly, bypassing the package maintainer.

We have a quick-doc about this already, which is being updated:

An article based on the quick-doc may perhaps suit the magazine, but a general discussion on this doesn’t fit (as @bcotton notes already)

1 Like