This is just a general front line support problem. A poor problem description or incomplete problem description is irritating and gets to people. The other one

This is just a general front line support problem. A poor problem description or incomplete problem description is irritating and gets to people. The other one is the people that only show you step #4 of a procedure they are using and keep trying to point to that as the root cause while it was really step #2. An issue report should show from damn near install to the observed problem, or thorough enough logs/config/stacktrace to give people on the receiving side enough information on how you got here. I call this the A-B-C-D problem, where they only keep telling you about something breaking in C but nothing about A, B or D that feeds in. The assume you may be wrong attitude to take in problem description is definitely something I have seen well received as a reporter and a recipient. Issues that are submitted with a tone of finality and then it turns into a problem resolved by configuration/FAQ/documentation can be frustrating, because in the triage you have to ignore such language and verify anyway. The unassertive language also clues the reader of potential knowledge gaps in the reporter. Inevitably just by construction of the report Also this was something that was mentioned in postgres response after I believe Uber transitioned from the technology to MySQL recently- if you are doing something massive/slightly insane it helps build a strategy. A communication issue from VPS host to VPS host for MySQL will require a different diagnostic strategy than microcontroller to microcontroller MySQL connection over an TCP/IP on I2C bus duct taped to the bottom of a Honda Civic.