This is a guide for connecting to our database for the purpose of submitting bug reports, reporting quirks, and participating in community discussion about user-submitted reports.

You are encouraged to visit frequently and to comment on reports that are of interest to you. You can comment via HelixChat or even better — directly within the Discussion section of each report. This discussion is our primary method of communicating about these reports. If we have questions or comments about a report, we ask them here.

The first step is (obviously) to log into techdb. If you are not familiar with this resource, click on this link to to to a page that tells you how to access it. Make sure that you register when you first log in, or you will not be able to submit a report.

Once you are logged in and registered, the various bug report views are found in the Bug Reports menu. The Bug Report Index lists the bugs that have already been entered, and Bug Report is the entry view you use to create new reports.

There are also three ways to search the existing bug reports:

1. Search Bug Reports uses keywords to search through the full list, helping you quickly determine whether somebody else has already reported the bug you are seeing.
2. Find My Bug Reports lets you review reports you have entered to see the current status of them. You can also see reports where you have contributed to the discussion.
3. Bug Report Index also has a Power Query attached, so it can be used to filter the reports as well.

Lastly, a hierarchical menu allows you to search the Error Codes Helix displays when a collection crashes. This is fairly technical information of limited use.

Once you have determined that your bug report is brand new, and nobody has reported it before, you should create a new report. This is the Bug Report form. (Point at the image to the right to see a full-size version of the form.)

Since this is Helix, filling out an entry view should be second nature to you. Nonetheless, a bit of guidance may prove useful. The form is divided into sections, with common fields grouped together…

1. Customer Info: Who you are. You must supply your customer number and access password to create a new report.
2. Helix Product: The product for which you are creating this report. Specify the product and the build number. Check the About Helix… window if you are not sure which version it is. You must supply a product and build number to create a new report.
3. System Info: Tell us a little about the Mac model and OS version you saw the bug on. Very seldom is a bug machine specific, but supplying that information may help us identify such a situation.
4. Bug Details: What sort of problem you are seeing. There are fields for specifying the type of problem (crash, cosmetic bug, etc.) the severity, whether it happens every time or not, and of course, a subject for and summary of the bug. Please try to make the subject short, but descriptive in a broad sense. When other users are searching the database for reports, you want them to be able to know what this bug is about just by reading the subject line.
5. Collection Information: If this bug is found in a specific collection you have, and you can not reproduce it in a new collection, tell us a little about the collection here. Most important is whether or not you can send a copy of the collection to us, upon request. Bugs that exist in specific collections can not be fixed unless we can see the bug in action. The only way to do that is for you to send us a copy of the collection. (But don't automatically send it; just let us know if we can have it when we need it.)
6. Support Documents: If you need to send us files to help us fix a bug, this section attaches them directly to the bug they relate to. You can attach crash logs and sample collections, but please don’t send screenshots of error dialogs. That is just a waste of space: report the contents of the error message in the Bug Details section instead. Likewise, pictures of views with problems aren’t particularly useful; chances are it will just look like a Helix view to us and mean little.
7. Discussion: This is the fun part. Everybody can join in on the conversation about your bug. Maybe somebody else has seen it too, and they can confirm it for us. Or maybe they have found a workaround that will help you get past it until we can fix it.
8. Votes: You are encouraged to vote on how important you think a particular bug is. We may think it is OK to defer a minor bug, but if lots of users tell us it is very important, we will reconsider. Votes are on a scale of 0-100.
9. Internal: If there is sensitive information you need to convey to us about the bug, this is the place to do so. Only QSA ToolWorks (and you) can see this information.

If your report is about a crash in an OS X Helix product, the OS X Crash Log can give us a great deal of detail about what went wrong in Helix. Please attach your crash logs when you submit a report related to a crash. The OS X Crash Logs page explains how to find the crash log and gives you more details about it.

Your responsibiltiy does not necessarily end once you have filed your bug report. The Status field (at the top of the entry view) tracks the state of your report. When you create the report, the status is set to new. When we get a chance to review it, we will change the status to reflect our thoughts. The status can change to:

1. Info Needed: We need more information from you.
2. Internal Testing: We have put it on the schedule to try to reproduce it.
3. Confirmed: We have successfullly reproduced the bug.
4. Deferred: We have successfullly reproduced the bug, but we will not be addressing it immediately.
5. Assigned: The bug is assigned to one of our engineers.
6. Retest: We think this bug is fixed, and want you to retest it. Next to the Status field will be a version number where we think the bug is fixed.
7. Fixed: We have fixed the bug with high degree of confidence. Next to the Status field will be the version number where the bug is fixed.
8. Can’t Fix: This is something we can not fix, probably because of a limitation in OS X or wxWidgets.
9. Works for Me: We can not reproduce this bug.
10. Later: We did not try to reproduce this bug, but we will try later. This is most common for cosmetic bugs.
11. Known Problem: This is already cataloged in the Known Problems section of our release notes.
12. Not a Bug: The behavior you describe is not considered buggy. Helix is performing as designed.
13. Won’t Fix: This may be a bug, but we are not going to address it. This is most common for bugs that we have to live with for one reason or another.
14. Duplicate: There is already a report for this bug. The original report number will be found in the Discussion section.
15. Closed: This report can no longer be modified. This is most common when a bug has been fixed for a long time and we are convinced it will not reappear in a subsequent release.

If the status change requires that you take further action to help us, please do what you can. The more you can do to help us isolate the bug, the faster we can fix it.

Bug reporing (done propertly) requires ongoing effort. We need you to work with us beyond the initial report. Check in on a regular basis and monitor the status of your reports. And when we think we have fixed your bug, test to make sure it is really fixed.

Finding and fixing bugs is also a community effort. Feel free to contribute to the discussion for other user’s bugs. We don’t intend for each report to be a conversation strictly between QSA ToolWorks and the reporter. The more Helix users who can provide pertinent discussion about a bug, the better our chances of understanding the problem and of fixing it. (And of knowing when our fixes really do fix it!)

The How To Get Your Bug Fixed page.

The Writing Good Reports page.