I've met with this attitude before. It's when developers interpret the function of QA to exclusively search for the situations where the expected functionality and actual don't match. They would reject anything coming from QA saying that the expected functionality is wrong.
So... do we restrict the meaning of the word "bug" only to the mismatched (developers') expectations, or do we extend it to cover bad expectations too? I'm in the later camp, because I'm not aware of even a single company that has any department or a process that would systematically address the existence of bad expectations. And, if anyone should be given the power to act on it, the QA seems to be the most likely candidate.
So... do we restrict the meaning of the word "bug" only to the mismatched (developers') expectations, or do we extend it to cover bad expectations too? I'm in the later camp, because I'm not aware of even a single company that has any department or a process that would systematically address the existence of bad expectations. And, if anyone should be given the power to act on it, the QA seems to be the most likely candidate.