In our organization we use a bug template that requires the following information when a bug is submitted:
- Short description of the bug
- Steps to reproduce the bug (this is a step by step procedure for reproducing the bug)
- Expected result (what did they expect to happen)
- Actual result (what actually happened)
- Software version and operating system
This is the minimum information required. We also ask for screenshots and application log files as appropriate for the bug in question.
We try to make our bug reporters report bugs from the users' perspective as much as possible. That makes it easier to assess the criticality of a bug more quickly so we can get it prioritized.
Tell them this is only an amateurish name for the Root Cause field used by professionals (when issue tracker does not have dedicated field, one can use comments for that).
Search the web for something like software bug root cause analysis, there are plenty of resources to justify this reasoning 1, 2, 3, 4, ....
...a root cause for a defect is not always a single developer (which is the main point of this field)...
That's exactly why "root cause" is professional while "person to blame" is amateurish. Personal accountability is great, but there are cases when it simply lays "outside" of the dev team.
Tell your boss when there is a single developer to blame, root cause field will definitely cover that ("coding mistake made by Bob in commit 1234, missed by Jim in review 567"). The point of using the term root cause is to cover cases like that, along with cases that go out of the scope of the dev team.
For example, if the bug has been caused by faulty hardware (with the person to blame being someone outside of the team who purchased and tested it), the root cause field allows for covering that, while "single developer to blame" would simply break the issue tracking flow.
The same applies to other bugs caused by someone outside of the dev team - tester errors, requirements change, and management decisions. Say, if management decides to skip investing in disaster recovery hardware, "blaming a single developer" for an electricity outage in the datacenter would just not make sense.
Best Answer
Thank them for the report. Reassure them you are listening to their feedback.
That you can't please everyone and that some people don't seem capable of not being rude.
You don't have to follow through on all the points that were brought up. It is your app and you decide where it goes. You will not be able to please everyone - so don't try. Make sure the group of people your app is for is catered for, but not everyone that uses it.