A blog I read from time to time had a short article complaining about "bug reports" and bemoaning the fact that users telling the programmers "it broke" was somehow not good enough. I have written articles about writing bug reports in magazines and books over the years, but apparently a "refresher" is needed every once in a while. Plus, containers, virtual machines, and more modern processors make things more complicated.

Specify the Problem

First, try to determine whether the problem is a true problem rather than you just do not know what to do when you want to do it. If it is the second issue, then search in whatever documentation exists. Many large applications (word processing systems, projects of every kind) have fairly good documentation in their online Help menu.

After looking through the documentation, you might search the Internet to see if someone else is having the same problem. A few well-worded queries in your favorite browser may find other people with the same problem, and you may find a way of working around the issue. If it still seems that people are just not understanding the documentation, then that is still a problem and should be reported. After all, it is causing people frustration and wasting time, so it is still a bug, but now you have more insight into the issue.

You now have done about all you can do before assuming the problem really is the application code, or perhaps the system. Next, you need to describe the problem to someone, somewhere, who can fix it.

Provide Information

Start gathering information about your problem. What software version and release number are you using? You can usually find this in the Help documentation. Do not only supply the application information, but also give information for the operating system on which you are running the application.

Include the distribution name (Ubuntu, Mint, Red Hat, etc.), version number, and release (or revision) number of the operating system. You also want to get the version number and release number of the kernel, which will probably be different. You can easily find the kernel information by typing in uname -a into a terminal emulator, for example:

$ uname -a:
Linux shaman 5.4.0-80-generic #90~18.04.1-Ubuntu SMP Tue
 Jul 13 19:40:02 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

To find the information you need for the kernel, look at the output following the name of your machine, in this example "shaman".

What architecture is your system? Is it Intel, AMD, ARM, or RISC-V? How many cores does your processor have, or specifically, what is your processor's model number?

How much main memory do you have?

Are you running the operating system in a virtual machine (VM)? What is the VM's version and what are the settings?

Are you running the application in a container? Give as much information about the container as possible.

Try to make your environment as simple as possible. See if the problem remains when you run it directly on a distribution and the distribution directly on the hardware of the machine.

To make this a lot easier, many systems have a command that tells you all the necessary information with one click. All you have to do is cut and paste or direct the information into a file.

If your application uses a browser, state which browser name and version you are using.

Report the Facts

Now you should make a clear statement of what is wrong. Be as precise as possible. Do not say "it broke." What "broke"? What did the program do or not do? Take a screen shot, if possible. Supply an example of input and output.

If the system crashed, do not just say "it crashed." It may have been the web browser, the X server, or the operating system. Be clear: "The X-server seems to have crashed. The screen went blank for a couple of seconds, but it came back quickly." Or perhaps, "The screen went blank and the operating system rebooted."

If the system is "hung," describe what else happens. Is it only one window that is not responsive or all the windows? Does anything move or react?