This is an old revision of the document!


Writing Useful Bug Reports

Adapted from this page at the qTox wiki article, in turn adapted from the Textmate wiki article.

What To Include

Adapted from the guide in the textmate/textmate repository

A good bug report must include the following four things:

  1. The steps to reproduce the bug: Give detailed steps on how to reproduce the problem.
    • Start from scratch
    • Explicitly mention every action involved, and how you invoked it (e.g., rather than “delete the text”, say “Select Cut from the context menu”)
  2. The expected behavior of the application: It’s important to include the result you’re expecting, as it might differ from how the program was designed to work.
  3. The observed behavior of the application: This is also important, since it’s possible that following your steps on a different system doesn’t reproduce the issue.
    • Include the data found in your qtox.log file. You can find the log in ~/.config/tox/ on UNIX-like platforms, and in %APPDATA\tox\ on Windows. Do not paste the log directly into the report. Post it somewhere else (e.g. Gist or Pastebin) and link to it.
  4. Information about your environment/platform
    • Include the operating system name/version
    • Include the version of qTox you are using. You can find a commit hash in the About tab in the settings menu.
    • If you are able to test multiple operating systems, do so
    • If your problem involves hardware, include information about that hardware
    • If your problem involves a crash, provide a backtrace

Providing Backtraces

If you are familiar with your platform's debugging tools, and your bug involves your Tox client crashing, some of the most useful info you can provide would be found in a backtrace.

To acquire a backtrace, you will need to use the debugger appropriate for your platform. For Unix-Like systems that will probably be gdb. You will also need to use the latest debug build of your Tox client. Debug binaries are available for most clients and the core library, but you don't have to use them if you know how to compile Tox with debugging symbols included.

Acquiring a Backtrace

Bug Report Template

When reporting bugs, you may choose to use the following template, either in its entirety, or with non-applicable sections left out.

Brief Description:

Operating System: Windows / OS X / Linux (include version and/or distro)
Hardware: 
…

Reproducible: Always / Almost Always / Sometimes / Rarely / Couldn't Reproduce

Steps to reproduce:
1. 
2. 
3. 
…

Observed Behavior:

Expected Behavior:

Additional info:
(links, images, etc go here)

If your issue includes images, upload them to github. Don't use imgur, etc.

If you're using multiple embedded images, be sure to include a description for every image, preferably using the following format:

++++++++
+IMAGE1+
++++++++
↑ *Description of Image 1*

++++++++
+IMAGE2+
++++++++
↑ *Description of Image 2*

Misc. Bug Reporting Tips

  1. Always include text in English. If your English is not very good, you may optionally include text in your native language, so that someone else may attempt to translate it more appropriately for you.

Misc. Troubleshooting

Some tips for troubleshooting Tox Clients include:

  1. Use Echobot for testing audio. If you start a voice/video call with Echobot, it will echo back all audio you send it with a 1-2 second delay. Echobot's ID can be found at Toxme

Reading Material

If you'd like to read other articles describing methods for writing bug reports, the following list contains a few very good picks:

Print/export