[Almad]

I'd agree with you if I would be only seeing the teams through my management reports and not from the trenches.

I am envious of the environment where you never saw somebody trying to bug feature request as a bug. I do think in a lot of cases, it's a judgement call...or a habit where problems perceived as bugs by customers are swung under the carpet as features as bug is only defined as "deviation from requirements".

Fair on distinction of severity by customer vs priority by team, although I am used to make a distinction between support ticket by customer and issue in engineering team's queue.

Lead implies either managerial or technological leadership and especially in mature organisations, I've seen both.

My experience with management by bug statistics is...very inconsistent as it motivates people to game the system...and boy I've seen that a lot. I do agree trend knowledge helps, but I am not sure it's worth the side-effects and work.

Of course, a flavor of this depends on context (and scale). It is very different if you have a single-instance SaaS, distributed system or images shipped to air-gapped systems.

[mytailorisrich]

> I am envious of the environment where you never saw somebody trying to bug feature request as a bug.

Really, I have never seen that in 20 years.

Of course that is different from another team or the test team raising a bug because they expected something that was not in the spec. Then you tell them that it's not because it does not behave the way they want that it is a bug. But, yes, a defect (more general term than bug) is any deviation from requirements.

Direct input from customers is different as well. Unless there is a contractual impact, if a customer is adamant something is a bug when it technically isn't then there is no point arguing. You can treat the request however you want internally.