Wednesday, November 12, 2014
How to properly submit a bug report
Altium is changing, and fast. The company structure and the tools itself are moving at a lightening pace and so it is inevitable that some problems creep in during the changes. The fact of the matter is any tool with this complexity will have bugs...period. How the users report the bugs back to the company can make a huge impact on how quickly the bug can be squashed. Here is a collection of tips acquired across the internet and personal experience that will make your bug reporting more effective. If you glean nothing from this, then great job! Keep the bug reports coming.
First off, a bug report is not a place to rant about the problems it has given you. Yes, it should be noted right away whether the bug is a critical (a crash the whole system bug) or a minor annoyance such as the cursor getting stuck behind the window occasionally while zooming. However, if you go on for half a page of capital letters describing your frustration and not the real problem, it is likely that the report will not be heard well.
So stick to only one bug at a time and only the facts of that one bug. And yes, everything should be factual, and as concise as possible. Do not write a paragraph about the hoops that you jump through when the steps to repeat the bug can be broken into a numbered list. In fact, if you cannot make a numbered list to accurately reproduce the bug each and every time, you may want to rethink submitting the report in the first place. Making an AE paw through a long report only to not be able to reproduce the bug takes away valuable time from another bug that could be crushed quickly.
Remember that the bug may have extenuating circumstances. For example, does the bug happen no matter what state the program is in? Maybe the bug is database related and not software related. Maybe the bug only shows up after a certain other action is performed. It may even be the influence of a third-party software (I utilize a screenshot program that can sometimes cause keys in Altium to lock up, but that is not an Altium bug). To get to the root of the issue, you should clear the system before you make your numbered list how to reproduce it. Restart Altium, even restart your whole system to ensure you have a clean slate. Then make the bug happen. If you can, now you can file a report.
Lastly, include any other support information that is required to reproduce the bug. For example, a screenshot (or 8) may be helpful for the AE to see exactly what you are looking at. Include the database files if the bug only appears with certain files. Include contact info so that someone can get back to you to further discuss the bug if they get stuck somewhere in the process and cannot reproduce it.
Since lots of us learn from an example far better than reading a collection of tips...*raises hand*...below is a sample report that is a real world Altium issue still in place now. My goal is to get you to the problem with no other support evidence. Take a step into the AE shoes and see if this guides you to the problem well.
Poor Example
Dear Altium,
Long ago you added mechanical layers extending from only 16 layers up to 32. However, we still, STILL do not have the ability to suppress layers 17-32 in the outjob setups! For example, when creating final artwork prints, everything on all layers from17-32 will show up on all pages of the printout. These have to be manually removed and are a serious headache to deal with. Please fix this ASAP!
Signed,
A bad reporter.
The info is there, there is a legit concern, but unless you are intimately familiar with this function, I doubt the above info will get you there.
Good Example
Dear Altium,
This is not really a bug report, but more of a feature enhancement to keep up to date with the current mechanical layer configuration. The enhancement is not critical, but would ultimately save hours of time in data manipulation. Currently, I treat mechanical layers 17-32 as though they are not there because of this problem.
Database preparation
1. Start a new or existing project, PCB and outjob file
2. Ensure there are a few copper features to have something to print
3. Enable mechanical layers 1,2,17,18 and add a couple items to these 4 mechanical layers.
Problem Tracking
1. Now that the database is all setup, open the Outjob file
2. Go to Fabrication Outputs and Add New Fabrication Output
a. In the popup menu choose Final->[PCB Document]
3. Double click on the new Final Artwork Prints output to get into the Configuration (PCB Printout Properties dialog box)
a. Note that for every printout, the applicable copper layers are present as well as all 4 of the mechanical layers we setup (1,2,17,18)
4. Click Preferences in the lower left corner of the current dialog box.
5. Uncheck Mechanical 1 and Mechanical 2 in the Include on New Printouts section.
a. Choose OK which will take you back to the PCB Printout Properties dialog box
6. Right click on any Printout (grey line near the top left corner) and click Create Final
7. Confirm the recreation of the print by clicking Yes.
8. Note now that Mechanical layers 1 and 2 are not included in the printouts, but mechanical layers 17 and 18 are still included in all prints. This is the real problem. Mechanical layers 17-32 cannot be removed automatically, but must be removed manually from every printout every time these prints are regenerated. Please add check boxes for mechanical layers 17-32 so that these layers become much more user friendly. Please contact me if more information is needed to see the issue.
Signed,
A much better reporter.
(123) 456-7890
much@better.com
Hope this helps!
Labels:
Bugs
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment