How to handle bug report

I recently tested the Go language (a language invented by a star-studded team, including the original inventor of C language and Unix), however, it didn't go smoothly.

I encountered a problem: I cannot compile a simple hello world program. It gave out a cryptic error message which search engines of the world cannot find.

Concerned, I raised a bug report. Mind you, it's not a support request, not a question. It's a __BUG REPORT__.

I received two kind of responses.

(1) The first one was short and sweet, and closed the ticket immediately, basically telling me not to ask question there.

But I wasn't asking a question. I was reporting what I thought to be a BUG!

This very unhelpful response was a big turn off. How would you encourage people to use your product if you ignore bug reports on your public bug tracker?

I quickly replied that with a piece of my mind.

My retort attracted a second response.

(2) This second response was a lot more helpful. It gently informed me that this was probably the problem of my own making; it linked to another ticket which had similar symptoms to the one I reported, and showed me how my issue could be caused by the same problem as described in the other ticket.

This response motivated me to do more investigation, and it turned out that the problem was indeed on my side. Hence, I replied in kind and moved on, after thanking the second responder.

No cookie for correctly guessing which one wins another customer (if this were a commercial project).


So what's the outtake here?

With response (2): I learn that Go uses files with the name of .a that aren't libraries, and therefore should not be stripped.

But more importantly, others will learn the same thing (once the issue is indexed by search engines, next time someone else tries looking it up, they won't find empty results).

And finally, perhaps, just perhaps, the Go developers themselves will learn that adopting a file extension (.a) that already has an existing, different meaning, is probably not the best idea.

What do we learn from response (1)? Go away, and Go use another language.


Sadly, attitude like (1) is very common on the IT world - especially in the commercial world. (I know Go isn't commercial, but I'm willing to bet that most of its core developers and support persons are employees).

Read the whole saga yourself:

Posted on 8 Jan 2022, 23:16 - Categories: General
Edit - Delete

No comments posted yet.

Add Comment

Show Smilies
Security Code 7485493
Mascot of Fatdog64
Password (to protect your identity)