How to Give Awesome Feedback


Other than asking that you keep each bug report or feature request post to a single, specific subject, feedback about software doesn't have to be exact. With that said, the more you are able to communicate what it is you would or would not like to experience, the more likely you will be to see your report or request get addressed. When it specifically comes to reporting bugs, we urge you to always try to explain the steps we can take to reproduce the problem.

While various publishers tend to lock themselves into list of rules of one type or another for reporting, we at Ascendant Design and Training know that the most important things in testing are to understand what went wrong, how to fix it, and what we can do to improve the product for you, the people who use it.

We provide the following reporting guidelines for your convenience only. Although one or more of them could give you an idea of how you would like to detail your next submission, your bug report or feature request forms are not required to include them. Use any of the following highlights where they make most sense.


Things to Include In Your Note

Following are some of the things to provide remarks about when creating a bug report or feature request.




Categories for Public Software Reporting

The more information you can provide about what you've found, the easier it is to resolve a request.



Following are the commonly recognized levels of severity.



You might start a new issue about of or more of the following environments.


Reproducing an Error

When reporting errors, the most helpful information for us is typically a step-by-step description of how you were able to get to that point.

In the following example, the steps lead to reproducing an error.