How to report a bug

Reporting a bug can be a detailed process. First and foremost, we the developers need to be able to reproduce the behaviour. If we can’t see the problem, we won’t be able to fix it. Sometimes this means we need to know more information about how you got to the the point where you noticed the behaviour – including information about your system and even possibly the data you’re using.

Using these guidelines we hope to be able to generate bug reports that allow us to fix issues with TrueNorth effectively.

Note: these instructions assume you’ve downloaded TrueNorth – either the demo version or one of the releases, and have an account on this system.

Search the Bug Report Forum for similar reports

Often, someone else has already reported the issue you’re dealing with. The Bug Report forum will have a list of previously posted bugs, and you can search through them.

Have the most recent version of TrueNorth.

Sometimes we’ve already noticed and fixed the issue. You can always download the most recent version of TrueNorth by going to your account page and clicking on the version of TrueNorth you purchased, or the demo version. You can always download a new Demo version of TrueNorth.

Create a new post for each bug

Don’t report more than one bug per post.

To create a new post, use the New Topic button, or use the button below

Report Bug

Give the Bug Report a descriptive name

The title of the post will allow other users to find your bug, and it also can give the developers a good idea what the bug is about.

Report the bug

Include the following details

  1. A clear unique summary of the bug.
    1. What happened
    2. What you expected to happen.
    3. Additional details if you have them – computer, Operating system, etc.
  2. A stack trace (output from an error dialog box)  you can copy and paste this into the post and it is the most valuable thing you can report
  3. The steps to reproduce the bug – you should attempt to re-create the situation on your own computer.
  4. Descrive

Examples

Summary

A good summary should quickly and uniquely identify a bug report. It should explain the problem, not your suggested solution.

Good: “Cancelling a File Copy dialog crashes File Manager”
Bad: “Software crashes”

Good: “Down-arrow scrolling doesn’t work in <textarea> styled with overflow:hidden”
Bad: “Browser should work with my web site”